|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.3-testing test] 24618: regressions - FAIL
flight 24618 xen-4.3-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/24618/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-oldkern 4 xen-build fail in 24610 REGR. vs. 24591 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-credit2 8 debian-fixup fail pass in 24610 test-amd64-amd64-xl-win7-amd64 7 windows-install fail pass in 24598 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 24610 pass in 24618 test-amd64-i386-freebsd10-i386 3 host-install(3) broken in 24598 pass in 24618 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail like 24591 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass test-armhf-armhf-xl 5 xen-boot fail never pass test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail in 24598 never pass version targeted for testing: xen c450908dc9168c3f20787aab268fcc295feaed7d baseline version: xen 0ac5c121734c5055ba2b500b7f515a71800c7b20 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Don Slutz <dslutz@xxxxxxxxxxx> Frediano Ziglio <frediano.ziglio@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Jun Nakajima <jun.nakajima@xxxxxxxxx> Keir Fraser <keir@xxxxxxx> Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> Tim Deegan <tim@xxxxxxx> Yang Zhang <yang.z.zhang@xxxxxxxxx> ------------------------------------------------------------ jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-i386-xend-qemut-winxpsp3 fail test-amd64-amd64-xl-qemut-winxpsp3 fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit c450908dc9168c3f20787aab268fcc295feaed7d Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Jan 29 11:56:17 2014 +0100 x86: don't drop guest visible state updates when 64-bit PV guest is in user mode Since 64-bit PV uses separate kernel and user mode page tables, kernel addresses (as usually provided via VCPUOP_register_runstate_memory_area and possibly via VCPUOP_register_vcpu_time_memory_area) aren't necessarily accessible when the respective updating occurs. Add logic for toggle_guest_mode() to take care of this (if necessary) the next time the vCPU switches to kernel mode. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 231d7f4098c8ac9cdb78f18fcb820d8618c8b0c2 master date: 2014-01-23 10:30:08 +0100 commit affb7e6bc3d3db4880613cf012b8f6cee0fd9c07 Author: Yang Zhang <yang.z.zhang@xxxxxxxxx> Date: Wed Jan 29 11:55:41 2014 +0100 Nested VMX: prohibit virtual vmentry/vmexit during IO emulation Sometimes, L0 needs to decode L2's instruction to handle IO access directly. And L0 may get X86EMUL_RETRY when handling this IO request. At same time, if there is a virtual vmexit pending (for example, an interrupt pending to inject to L1) and hypervisor will switch the VCPU context from L2 to L1. Now we already are in L1's context, but since we got a X86EMUL_RETRY just now and this means hypervisor will retry to handle the IO request later and unfortunately, the retry will happen in L1's context. And it will cause the problem. The fixing is that if there is a pending IO request, no virtual vmexit/vmentry is allowed. Signed-off-by: Yang Zhang <yang.z.zhang@xxxxxxxxx> Acked-by: Jun Nakajima <jun.nakajima@xxxxxxxxx> master commit: 09bb434748af9bfe3f7fca4b6eef721a7d5042a4 master date: 2014-01-23 10:27:34 +0100 commit a4c215abc86dad8ccca4992f14f62550e5c02cf6 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Jan 29 11:54:32 2014 +0100 common/sysctl: Don't leak status in SYSCTL_page_offline_op In addition, 'copyback' should be cleared even in the error case. Also fix the indentation of the arguments to copy_to_guest() to help clarify that the 'ret = -EFAULT' is not part of the condition. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: efd8ff0a04740a698b2b8b2b9adccd639e0fa6c9 master date: 2014-01-20 09:48:11 +0100 commit f7d6d69edc9c98d25c2b2300eb925bec637d0b2e Author: Yang Zhang <yang.z.zhang@xxxxxxxxx> Date: Wed Jan 29 11:54:02 2014 +0100 nested EPT: fixing wrong handling for L2 guest's direct mmio access L2 guest will access the physical device directly(nested VT-d). For such access, Shadow EPT table should point to device's MMIO. But in current logic, L0 doesn't distinguish the MMIO whether from qemu or physical device when building shadow EPT table. This is wrong. This patch will setup the correct shadow EPT table for such MMIO ranges. Signed-off-by: Yang Zhang <yang.z.zhang@xxxxxxxxx> Acked-by: Tim Deegan <tim@xxxxxxx> master commit: 0b988ba711171b39aed9851cfe90fded50f775c5 master date: 2014-01-17 16:00:21 +0100 commit 9c5b7fb63a79570e4bc14fcbe2d15a23a0f1b433 Author: Frediano Ziglio <frediano.ziglio@xxxxxxxxxx> Date: Wed Jan 29 11:53:22 2014 +0100 mce: fix race condition in mctelem_xchg_head The function (mctelem_xchg_head()) used to exchange mce telemetry list heads is racy. It may write to the head twice, with the second write linking to an element in the wrong state. If there are two threads, T1 inserting on committed list; and T2 trying to consume it. 1. T1 starts inserting an element (A), sets prev pointer (mcte_prev). 2. T1 is interrupted after the cmpxchg succeeded. 3. T2 gets the list and changes element A and updates the commit list head. 4. T1 resumes, reads pointer to prev again and compare with result from the cmpxchg which succeeded but in the meantime prev changed in memory. 5. T1 thinks the cmpxchg failed and goes around the loop again, linking head to A again. To solve the race use temporary variable for prev pointer. *linkp (which point to a field in the element) must be updated before the cmpxchg() as after a successful cmpxchg the element might be immediately removed and reinitialized. The wmb() prior to the cmpchgptr() call is not necessary since it is already a full memory barrier. This wmb() is thus removed. Signed-off-by: Frediano Ziglio <frediano.ziglio@xxxxxxxxxx> Reviewed-by: Liu Jinsong <jinsong.liu@xxxxxxxxx> master commit: e9af61b969906976188609379183cb304935f448 master date: 2014-01-17 15:58:27 +0100 commit df75a2685c21158817092e34ee20cbf7ca770e75 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Jan 29 11:52:14 2014 +0100 dbg_rw_guest_mem: need to call put_gfn in error path Using a 1G hvm domU (in grub) and gdbsx: (gdb) set arch i8086 warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration of GDB. Attempting to continue with the default i8086 settings. The target architecture is assumed to be i8086 (gdb) target remote localhost:9999 Remote debugging using localhost:9999 Remote debugging from host 127.0.0.1 0x0000d475 in ?? () (gdb) x/1xh 0x6ae9168b Will reproduce this bug. With a debug=y build you will get: Assertion '!preempt_count()' failed at preempt.c:37 For a debug=n build you will get a dom0 VCPU hung (at some point) in: [ffff82c4c0126eec] _write_lock+0x3c/0x50 ffff82c4c01e43a0 __get_gfn_type_access+0x150/0x230 ffff82c4c0158885 dbg_rw_mem+0x115/0x360 ffff82c4c0158fc8 arch_do_domctl+0x4b8/0x22f0 ffff82c4c01709ed get_page+0x2d/0x100 ffff82c4c01031aa do_domctl+0x2ba/0x11e0 ffff82c4c0179662 do_mmuext_op+0x8d2/0x1b20 ffff82c4c0183598 __update_vcpu_system_time+0x288/0x340 ffff82c4c015c719 continue_nonidle_domain+0x9/0x30 ffff82c4c012938b add_entry+0x4b/0xb0 ffff82c4c02223f9 syscall_enter+0xa9/0xae And gdb output: (gdb) x/1xh 0x6ae9168b 0x6ae9168b: 0x3024 (gdb) x/1xh 0x6ae9168b 0x6ae9168b: Ignoring packet error, continuing... Reply contains invalid hex digit 116 The 1st one worked because the p2m.lock is recursive and the PCPU had not yet changed. crash reports (for example): crash> mm_rwlock_t 0xffff83083f913010 struct mm_rwlock_t { lock = { raw = { lock = 2147483647 }, debug = {<No data fields>} }, unlock_level = 0, recurse_count = 1, locker = 1, locker_function = 0xffff82c4c022c640 <__func__.13514> "__get_gfn_type_access" } Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Signed-off-by: Don Slutz <dslutz@xxxxxxxxxxx> Acked-by: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> master commit: 3dbab7a8bf4bef1bb2967cb3a8c7ed2146482ab3 master date: 2014-01-10 17:45:01 +0100 (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |