[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.4-testing test] 28810: regressions - trouble: broken/fail/pass
flight 28810 xen-4.4-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/28810/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pv 3 host-install(3) broken REGR. vs. 27490 test-amd64-i386-xl-credit2 3 host-install(3) broken REGR. vs. 27490 test-amd64-amd64-pv 3 host-install(3) broken REGR. vs. 27490 test-amd64-i386-freebsd10-amd64 3 host-install(3) broken REGR. vs. 27490 test-amd64-i386-xl 3 host-install(3) broken REGR. vs. 27490 test-amd64-amd64-xl-win7-amd64 3 host-install(3) broken REGR. vs. 27490 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 27490 test-amd64-amd64-pair 3 host-install/src_host(3) broken REGR. vs. 27490 test-amd64-amd64-pair 4 host-install/dst_host(4) broken REGR. vs. 27490 test-amd64-i386-xl-win7-amd64 3 host-install(3) broken REGR. vs. 27490 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate.2 fail REGR. vs. 27490 test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken REGR. vs. 27490 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 27490 test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 27490 test-armhf-armhf-libvirt 3 host-install(3) broken REGR. vs. 27490 test-amd64-i386-xend-qemut-winxpsp3 3 host-install(3) broken REGR. vs. 27490 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken REGR. vs. 27490 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-pcipt-intel 3 host-install(3) broken REGR. vs. 27490 test-amd64-amd64-xl-sedf-pin 3 host-install(3) broken REGR. vs. 27490 test-amd64-amd64-xl-sedf 3 host-install(3) broken REGR. vs. 27490 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 9 guest-start fail never pass test-armhf-armhf-xl 10 migrate-support-check fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 17 leak-check/check fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen ee81dda7c3767bd9af7ae84a86d1be56d8fad343 baseline version: xen 7aedb244ed6ca3180849fe4a04136a2b10151327 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Dario Faggioli <dario.faggioli@xxxxxxxxxx> Ian Campbell <ian.campbell@xxxxxxxxxx> Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Julien Grall <julien.grall@xxxxxxxxxx> Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> ------------------------------------------------------------ jobs: build-amd64-xend pass build-i386-xend pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt 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 broken 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 broken test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 broken test-amd64-amd64-xl-qemuu-ovmf-amd64 broken test-amd64-i386-xl-qemuu-ovmf-amd64 broken test-amd64-amd64-rumpuserxen-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 broken 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 broken test-amd64-i386-xl-win7-amd64 broken test-amd64-i386-xl-credit2 broken test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumpuserxen-i386 pass test-amd64-amd64-xl-pcipt-intel broken test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt broken test-amd64-i386-libvirt fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair broken test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin broken test-amd64-amd64-pv broken test-amd64-i386-pv broken test-amd64-amd64-xl-sedf broken 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 broken test-amd64-amd64-xl-qemut-winxpsp3 broken test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-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 ee81dda7c3767bd9af7ae84a86d1be56d8fad343 Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Thu Jul 3 13:58:23 2014 +0100 QEMU_TAG update - FIX! My qemu push and tag update script had transposed a revision number from qemu-xen-4.3-testing into xen-4.4-testing's Config.mk! The script is now fixed, but we also need to fix the tree. Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> commit 9fc0c44a691c5166908cf1015c4a73d65c711d04 Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Wed Jul 2 16:06:31 2014 +0100 QEMU_TAG update commit 34a314265f43113fc3e7f68ca04370541ea1e7c5 Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Thu May 22 10:46:37 2014 +0100 tools: arm: report an error if the guest RAM is too large Due to the layout of the guest physical address space we cannot support more than 768M of RAM before overrunning the area set aside for the grant table. Due to the presence of the magic pages at the end of the RAM region guests are actually limited to 767M. Catch this case during domain build and fail gracefully instead of obscurely later on. Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> (cherry picked from commit 5a959f44ed03398870b6ec0dfebb59dcd5981f94) commit d40bed867d9550afe3d6e7c369647905109ce831 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Jun 18 19:04:14 2014 +0100 tools/libxl: Fix free() of wild pointer in libxl__initiate_device_remove() libxl__initiate_device_remove() had a preexisting error path issue where libxl_dominfo_dispose() could be called on a libxl_dominfo object before it had been initialised with libxl_dominfo_init(). This was safe until c/s ab44401 added the pointer ssid_label, which point libxl_dominfo_dispose() free()s. Unconditionally initialise info in libxl__initiate_device_remove() before taking an error path which will free it. Coverity-ID: 1223212 Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> CC: Wei Liu <wei.liu2@xxxxxxxxxx> CC: Ian Campbell <Ian.Campbell@xxxxxxxxxx> CC: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> (cherry picked from commit ddb4aa5dfa13781e8f31ba20923c14c1a083ce83) commit 5e39eb05aa2a6d9bfa6c3b3e299b071422498625 Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Date: Fri Jun 20 16:09:00 2014 +0200 blktap2: Fix two 'maybe uninitialized' variables for which gcc 4.9.0 complains about, like this: block-qcow.c: In function `get_cluster_offset': block-qcow.c:431:3: error: `tmp_ptr' may be used uninitialized in this function [-Werror=maybe-uninitialized] memcpy(tmp_ptr, l1_ptr, 4096); ^ block-qcow.c:606:7: error: `tmp_ptr2' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (write(s->fd, tmp_ptr2, 4096) != 4096) { ^ cc1: all warnings being treated as errors /home/dario/Sources/xen/xen/xen.git/tools/blktap2/drivers/../../../tools/Rules.mk:89: recipe for target 'block-qcow.o' failed make[5]: *** [block-qcow.o] Error 1 The proper behavior is to return upon allocation failure. About what to return, 0 seems the best option, looking at both the function and the call sites. Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> (cherry picked from commit 345e44a85d71a1a910385f33c7f1ba3683026d18) commit d774a33b72b933ef425f52cb771dee60e809201e Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Thu Jun 26 17:30:14 2014 +0100 xen: arm: make sure gcc doesn't use floating-point registers on arm64 By using -mgeneral-regs-only which is the Aarch64 equivalent to -msoft-float. Otherwise gcc will corrupt the d* registers, which we don't save/restore when trapping to/from the hypervisor. Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxxxxx> (cherry picked from commit c0726c18e8135f87a5a5793d993d6bea1e3fa925) commit c2800a8f93c828671ee4b2517accea8c546eb883 Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Fri Jun 13 13:15:04 2014 +0100 xen: arm: Implement OSDLR_EL1 trap as RAZ/WO. I'm not sure why this wasn't added at the same time as the other debug registers. Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxxxxx> (cherry picked from commit 92b0b80f0d2d29d0e80bf35ea839ed6058b7f0fa) commit 652fb44ffbc5f3ff576b6d2349a49910170e7d2b Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Thu Jun 26 09:53:42 2014 +0100 xen: arm: take FIQ exceptions to Xen not guest by setting HCR_EL2.FMO As with HCR_EL2.{IMO,AMO} we want to route FIQs to Xen not the guest. See ARM ARM DDI 0406C.b B1.8.4. So far none of the platforms which we support use FIQ for anything, but when we end up supporting one it would be far better to surprise Xen with them than whatever guest happens to be running... Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxxxxx> (cherry picked from commit 4bb74e39987b428429c2aacad7f59356d4942e39) Conflicts: xen/arch/arm/traps.c commit 3ca5033563bd736f5d153a59fae7c02ec3a5abce Author: Julien Grall <julien.grall@xxxxxxxxxx> Date: Thu Apr 24 23:45:55 2014 +0100 xen/arm: Implement a dummy debug monitor for ARM32 XSA-93 (commit 0b18220 "xen/arm: Don't let guess access to Debug and Performance Monitors registers") disable Debug Registers access. When CONFIG_PERF_EVENTS is enabled in the Linux Kernel, it will try to initialize the debug monitors. If an error occured Linux won't use this feature. The implementation made Xen expose a minimal set of registers which let think the guest (i.e.) thinks HW debug won't work. Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> [ ijc -- s/DBGCR/DBGBCR/ to use correct register name ] Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> (cherry picked from commit 68c69978352adb5ab7c06598056f9eb88d7d6031) [ ijc -- s/is_32bit_domain/is_pv32_domain/ ] commit d7b4272ae4c14560b90327808425a2c1304b84fc Author: Julien Grall <julien.grall@xxxxxxxxxx> Date: Thu Apr 24 23:45:54 2014 +0100 xen/arm: Implement a dummy Performance Monitor for ARM32 XSA-93 (commit 0b18220 "xen/arm: Don't let guess access to Debug and Performance Monitor registers") disable Performance Monitor. When CONFIG_PERF_EVENTS is enabled in the Linux Kernel, regardless the ID_DFR0 (which tell if Perfomance Monitors Extension is implemented) the kernel will try to access to PMCR. Therefore we tell the guest we have 0 counters. Unfortunately we must always support PMCCNTR (the cycle counter): we just RAZ/WI for all PM register, which doesn't crash the kernel at least. Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> (cherry picked from commit aa0d443718372b46c432af7cb6274050cda32fc6) commit 0424674f3fa98b7792c838725fbf5623258698b1 Author: Julien Grall <julien.grall@xxxxxxxxxx> Date: Tue Jun 17 21:44:28 2014 +0100 xen/arm: Panic when we receive an unexpected trap The current implementation of do_unexpected_trap make Xen spin forever on the current physical CPU. This may lead to stall guests VCPU and print unhelpful message (RCU stall...). Usually when Xen receives an unexpected trap, it means that something goes wrong either in the hypervisor or in the CPU. In this case we should directly panic to also stop the other CPUs. Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> (cherry picked from commit 4f5ab681d208993f94553203f4be323b3c929070) (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 |