|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable test] 34484: regressions - FAIL
flight 34484 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34484/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 13 guest-destroy fail REGR. vs. 34341 Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail like 34341 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-sedf 10 migrate-support-check fail never pass test-armhf-armhf-xl-midway 10 migrate-support-check fail never pass test-armhf-armhf-libvirt 10 migrate-support-check fail never pass test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-check fail never pass test-armhf-armhf-xl 10 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-check fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-libvirt 10 migrate-support-check fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-armhf-armhf-xl-credit2 10 migrate-support-check fail never pass test-amd64-i386-libvirt 10 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen d40cbb98a3eb447b8055ec4e70e93a6f22850ac5 baseline version: xen 001324547356af86875fad5003f679571a6b8f1c ------------------------------------------------------------ People who touched revisions under test: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Paul Durrant <paul.durrant@xxxxxxxxxx> Wei Liu <wei.liu2@xxxxxxxxxx> ------------------------------------------------------------ jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-armhf-pvops pass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-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-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumpuserxen-i386 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-amd64-xl-pvh-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass test-armhf-armhf-xl-midway pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair fail test-amd64-amd64-xl-sedf-pin pass test-armhf-armhf-xl-sedf-pin pass test-amd64-amd64-xl-sedf pass test-armhf-armhf-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-amd64-xl-qemut-winxpsp3 fail test-amd64-i386-xl-qemut-winxpsp3 fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xl-qemuu-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-amd64-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on osstest.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 d40cbb98a3eb447b8055ec4e70e93a6f22850ac5 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Feb 10 13:32:03 2015 +0100 x86: re-order struct arch_domain fields ... to reduce padding holes. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit afb2f2ffb72e38268bdd0c26ce7f3df90eea76bb Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Feb 10 13:31:16 2015 +0100 x86/HVM: also separate kernel/user vTSC statistics It is unclear why this got done for PV only originally. While at it, limit this statistics collection to debug or performance counter enabled builds. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit 70f691130081324a8efb97b23c504d8abc5421db Author: Paul Durrant <paul.durrant@xxxxxxxxxx> Date: Tue Feb 10 13:29:51 2015 +0100 x86/hvm: explicitly mark ioreq server pages dirty ...when they are added back into the guest physmap, when an ioreq server is disabled. If this is not done then the pages are missed during migration, causing ioreq server creation to fail on the remote end. This problem only manifests if the ioreq server is non-default because in the default case the pages are never removed from the guest physmap. Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> commit dd748d128d86996592afafea02e578cc7d4e6d42 Author: Paul Durrant <paul.durrant@xxxxxxxxxx> Date: Tue Feb 10 13:28:40 2015 +0100 x86/hvm: wait for at least one ioreq server to be enabled In the case where a stub domain is providing emulation for an HVM guest, there is no interlock in the toolstack to make sure that the stub domain is up and running before the guest is unpaused. Prior to the introduction of ioreq servers this was not a problem, since there was only ever one emulator so ioreqs were simply created anyway and the vcpu remained blocked until the stub domain started and picked up the ioreq. Since ioreq servers allow for multiple emulators for a single guest it's not possible to know a priori which emulator will handle a particular ioreq, so emulators must attach to a guest before the guest runs. This patch works around the lack of interlock in the toolstack for stub domains by keeping the domain paused until at least one ioreq server is created and enabled, which in practice means the stub domain is indeed up and running. Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> commit 8bc64413be51c91b8f5e790b71e0d94727f9f004 Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Mon Feb 9 15:34:40 2015 +0000 libxl: More probably detect reentry of destroyed ctx In libxl_ctx_free: 1. Move the GC_INIT earlier, so that we can: 2. Take the lock around most of the work. This is technically unnecessary since calling any other libxl entrypoint on a ctx being passed to libxl_ctx_free risks undefined behaviour. But, taking the lock allows us to much more usually spot this. 3. Increment osevent_in_hook by 1000. If we are reentered after destroy, this will trip some of our entrypoints' asserts. It also means that if we crash for some other reason relating to reentering a destroyed ctx, the cause will be more obviously visible by examining ctx->osevent_in_hook (assuming that the memory previously used for the ctx hasn't been reused and overwritten). 4. Free the lock again. (pthread_mutex_destroy requires that the mutex be unlocked.) With this patch, I find that an occasional race previously reported as: libvirtd: libxl_internal.h:3265: libxl__ctx_unlock: Assertion `!r' failed. is now reported as: libvirtd: libxl_event.c:1236: libxl_osevent_occurred_fd: Assertion `!libxl__gc_owner(gc)->osevent_in_hook' failed. Examining the call trace with gdb shows this: (gdb) bt #0 0xb773f424 in __kernel_vsyscall () #1 0xb7022871 in raise () from /lib/i386-linux-gnu/i686/nosegneg/libc.so.6 #2 0xb7025d62 in abort () from /lib/i386-linux-gnu/i686/nosegneg/libc.so.6 #3 0xb701b958 in __assert_fail () from /lib/i386-linux-gnu/i686/nosegneg/libc.so.6 #4 0xb6f00390 in libxl_osevent_occurred_fd (ctx=0xb84813a8, for_libxl=0xb84d6848, fd=31, events_ign=0, revents_ign=1) at libxl_event.c:1236 #5 0xb1b70464 in libxlDomainObjFDEventCallback () from /usr/local/lib/libvirt/connection-driver/libvirt_driver_libxl.so #6 0xb72163b1 in virEventPollDispatchHandles () from /usr/local/lib/libvirt.so.0 #7 0xb7216be5 in virEventPollRunOnce () from /usr/local/lib/libvirt.so.0 #8 0xb7214a7e in virEventRunDefaultImpl () from /usr/local/lib/libvirt.so.0 #9 0xb77c7b98 in virNetServerRun () #10 0xb7771c63 in main () (gdb) print ctx->osevent_in_hook $2 = 1000 (gdb) which IMO demonstrates that libxl_osevent_occurred_fd is being called on a destroyed ctx. This is probably a symptom of the bug in libvirt fixed by these patches: https://www.redhat.com/archives/libvir-list/2015-February/msg00024.html Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> CC: Ian Campbell <ian.campbell@xxxxxxxxxx> CC: Wei Liu <wei.liu2@xxxxxxxxxx> CC: Jim Fehlig <jfehlig@xxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit f1335f0d7b2402e94e0c6e8a905dc309edaafcfb Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Mon Feb 9 15:20:32 2015 +0000 libxl: event handling: ao_inprogress does waits while reports outstanding libxl__ao_inprogress needs to check (like libxl__ao_complete_check_progress_reports) that there are no oustanding progress callbacks. Otherwise it might happen that we would destroy the ao while another thread has an outstanding callback its egc report queue. The other thread would then, in its egc_run_callbacks, touch the destroyed ao. Instead, when this happens in libxl__ao_inprogress, simply run round the event loop again. The thread which eventually makes the callback will spot our poller in the ao, and notify the poller, waking us up. This fixes an assertion failure race seen with libvirt: libvirtd: libxl_event.c:1792: libxl__ao_complete_check_progress_reports: Assertion `ao->in_initiator' failed. or (after "Add an assert to egc_run_callbacks") libvirtd: libxl_event.c:1338: egc_run_callbacks: Assertion `aop->ao->magic == 0xA0FACE00ul' failed. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> CC: Ian Campbell <ian.campbell@xxxxxxxxxx> CC: Wei Liu <wei.liu2@xxxxxxxxxx> CC: Jim Fehlig <jfehlig@xxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 93699882d98cce9736d6e871db303275df1138a2 Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Mon Feb 9 15:18:30 2015 +0000 libxl: event handling: Break out ao_work_outstanding Break out the test in libxl__ao_complete_check_progress_reports, into ao_work_outstanding, which reports false if either (i) the ao is still ongoing or (ii) there is a progress report (perhaps on a different thread's callback queue) which has yet to be reported to the application. No functional change. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> CC: Ian Campbell <ian.campbell@xxxxxxxxxx> CC: Wei Liu <wei.liu2@xxxxxxxxxx> CC: Jim Fehlig <jfehlig@xxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 6b5a5bba1a8025040947f39f1c80012373f35efe Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Mon Feb 9 15:10:11 2015 +0000 libxl: event handling: Add an assert to egc_run_callbacks Check that the ao is still live when we are about to running some of its callbacks. This reveals an existing bug in libxl which is exercised by libvirt, converting libvirtd: libxl_event.c:1792: libxl__ao_complete_check_progress_reports: Assertion `ao->in_initiator' failed. into libvirtd: libxl_event.c:1338: egc_run_callbacks: Assertion `aop->ao->magic == 0xA0FACE00ul' failed. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> CC: Ian Campbell <ian.campbell@xxxxxxxxxx> CC: Wei Liu <wei.liu2@xxxxxxxxxx> CC: Jim Fehlig <jfehlig@xxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> (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 |