* [xen-4.3-testing test] 24610: regressions - FAIL
@ 2014-01-30 2:48 xen.org
0 siblings, 0 replies; only message in thread
From: xen.org @ 2014-01-30 2:48 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 24610 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/24610/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-oldkern 4 xen-build fail REGR. vs. 24591
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail pass in 24598
test-amd64-amd64-xl-win7-amd64 7 windows-install fail pass in 24598
test-amd64-i386-freebsd10-i386 3 host-install(3) broken in 24598 pass in 24610
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@citrix.com>
Don Slutz <dslutz@verizon.com>
Frediano Ziglio <frediano.ziglio@citrix.com>
Jan Beulich <jbeulich@suse.com>
Jun Nakajima <jun.nakajima@intel.com>
Keir Fraser <keir@xen.org>
Mukesh Rathor <mukesh.rathor@oracle.com>
Tim Deegan <tim@xen.org>
Yang Zhang <yang.z.zhang@Intel.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern fail
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 pass
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 fail
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@suse.com>
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@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 231d7f4098c8ac9cdb78f18fcb820d8618c8b0c2
master date: 2014-01-23 10:30:08 +0100
commit affb7e6bc3d3db4880613cf012b8f6cee0fd9c07
Author: Yang Zhang <yang.z.zhang@Intel.com>
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@Intel.com>
Acked-by: Jun Nakajima <jun.nakajima@intel.com>
master commit: 09bb434748af9bfe3f7fca4b6eef721a7d5042a4
master date: 2014-01-23 10:27:34 +0100
commit a4c215abc86dad8ccca4992f14f62550e5c02cf6
Author: Andrew Cooper <andrew.cooper3@citrix.com>
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@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: efd8ff0a04740a698b2b8b2b9adccd639e0fa6c9
master date: 2014-01-20 09:48:11 +0100
commit f7d6d69edc9c98d25c2b2300eb925bec637d0b2e
Author: Yang Zhang <yang.z.zhang@Intel.com>
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@Intel.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: 0b988ba711171b39aed9851cfe90fded50f775c5
master date: 2014-01-17 16:00:21 +0100
commit 9c5b7fb63a79570e4bc14fcbe2d15a23a0f1b433
Author: Frediano Ziglio <frediano.ziglio@citrix.com>
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@citrix.com>
Reviewed-by: Liu Jinsong <jinsong.liu@intel.com>
master commit: e9af61b969906976188609379183cb304935f448
master date: 2014-01-17 15:58:27 +0100
commit df75a2685c21158817092e34ee20cbf7ca770e75
Author: Andrew Cooper <andrew.cooper3@citrix.com>
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@citrix.com>
Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: Mukesh Rathor <mukesh.rathor@oracle.com>
master commit: 3dbab7a8bf4bef1bb2967cb3a8c7ed2146482ab3
master date: 2014-01-10 17:45:01 +0100
(qemu changes not included)
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2014-01-30 2:48 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-30 2:48 [xen-4.3-testing test] 24610: regressions - FAIL xen.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).