|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable test] 18537: regressions - FAIL
flight 18537 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/18537/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 4 xen-install fail REGR. vs. 18466 test-amd64-i386-rhel6hvm-intel 4 xen-install fail REGR. vs. 18466 test-amd64-i386-qemut-rhel6hvm-amd 4 xen-install fail REGR. vs. 18466 test-amd64-amd64-xl 4 xen-install fail REGR. vs. 18466 test-amd64-amd64-pv 4 xen-install fail REGR. vs. 18466 test-amd64-i386-rhel6hvm-amd 4 xen-install fail REGR. vs. 18466 test-amd64-i386-qemuu-rhel6hvm-amd 4 xen-install fail REGR. vs. 18466 test-amd64-amd64-pair 6 xen-install/dst_host fail REGR. vs. 18466 test-amd64-amd64-pair 5 xen-install/src_host fail REGR. vs. 18466 test-amd64-i386-xl-credit2 4 xen-install fail REGR. vs. 18466 test-amd64-amd64-xl-qemut-win7-amd64 4 xen-install fail REGR. vs. 18466 test-amd64-amd64-xl-qemuu-winxpsp3 4 xen-install fail REGR. vs. 18466 test-amd64-i386-xend-winxpsp3 4 xen-install fail REGR. vs. 18466 test-amd64-amd64-xl-qemuu-win7-amd64 4 xen-install fail REGR. vs. 18466 test-amd64-i386-qemut-rhel6hvm-intel 4 xen-install fail REGR. vs. 18466 test-amd64-amd64-xl-win7-amd64 4 xen-install fail REGR. vs. 18466 test-amd64-i386-xl-win7-amd64 4 xen-install fail REGR. vs. 18466 test-amd64-i386-pair 6 xen-install/dst_host fail REGR. vs. 18466 test-amd64-i386-pair 5 xen-install/src_host fail REGR. vs. 18466 test-amd64-i386-xl-qemut-win7-amd64 4 xen-install fail REGR. vs. 18466 test-amd64-amd64-xl-winxpsp3 4 xen-install fail REGR. vs. 18466 test-amd64-amd64-xl-qemut-winxpsp3 4 xen-install fail REGR. vs. 18466 test-amd64-i386-xl-winxpsp3-vcpus1 4 xen-install fail REGR. vs. 18466 test-amd64-i386-xend-qemut-winxpsp3 4 xen-install fail REGR. vs. 18466 test-amd64-i386-xl 4 xen-install fail REGR. vs. 18466 test-amd64-i386-xl-multivcpu 4 xen-install fail REGR. vs. 18466 test-amd64-i386-pv 4 xen-install fail REGR. vs. 18466 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 4 xen-install fail REGR. vs. 18466 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-pcipt-intel 4 xen-install fail REGR. vs. 18466 test-amd64-amd64-xl-sedf-pin 4 xen-install fail REGR. vs. 18466 test-amd64-amd64-xl-sedf 4 xen-install fail REGR. vs. 18466 version targeted for testing: xen 2a6327bf2bfaf5de5e07aed583d2c337c9d368c0 baseline version: xen d4435fe5e2f0dfadb41ef46c38f462f45d67762e ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Eric Trudeau <etrudeau@xxxxxxxxxxxx> Ian Campbell <ian.campbell@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Julien Grall <julien.grall@xxxxxxxxxx> Keir Fraser <keir@xxxxxxx> Sander Eikelenboom <linux@xxxxxxxxxxxxxx> Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> Tim Deegan <tim@xxxxxxx> Xiantao Zhang <xiantao.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-i386-pvops pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemut-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail 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-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemut-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair fail test-amd64-i386-pair fail test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv fail test-amd64-i386-pv fail test-amd64-amd64-xl-sedf fail test-amd64-i386-xl-qemut-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 2a6327bf2bfaf5de5e07aed583d2c337c9d368c0 Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Fri Apr 26 11:58:47 2013 +0100 xen: arm: drop LDFLAGS_DIRECT emulation specification. The current -maarch64elf fails when cross-building arm64 on Ubuntu Raring due to a missing file "ldscripts/aarch64elf.xr". This is undoubtedly an Ubuntu gcc bug, hwever when investigating I found that this option was not necessary at all since we provide an explicit linker script when linking the hypervisor (AFAICT all -m<foo> does is override the default linker script). LDFLAGS_DIRECT is also used when linking the intermediate built-in.o files but -m<emulatin> is not needed for this since it isn't linking the final image and we are calling the linker with the correct, cross if necessary, name. However it does appear to be potentially useful to supply -EL in both cases to ensure that we get little endian images. (I just happened to spot that Linux does this, for both arm and arm64, although I expect we are unlikely to trip over such toolchains these days). Tested with cross-builds of arm32 and arm64 as well as a native arm32 build. Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Acked-by: Tim Deegan <tim@xxxxxxx> commit bbccf0d088d2041d95ede1d59fc195205f932f38 Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Thu Apr 25 15:45:50 2013 +0100 xen: arm: enable aborts on all physical processors. I'm not sure how this ended up in construct dom0 where it only affects the boot cpu and doesn't logically fit. Enable aborts at the same time as we enable interrupts. I'm not sure what the behaviour of an "abort worthy" operation while aborts are disable is, but it must surely be worse than calling do_unexpected_trap, which is what happens from now on. Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Acked-by: Tim Deegan <tim@xxxxxxx> commit c57c50c1de759583d5de629fec205254280da4f0 Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Wed Jul 17 12:18:51 2013 +0100 xen: arm: clear the exclusive monitor on exception return Otherwise context switching between two vcpus which are contending the same lock can result in a spurious success. Our spinlock and atomics code (which we get from Linux) rely on this behaviour because they use non-exclusive stores for single instruction operations (e.g. spin_unlock or atomic_set). This is not required on ARMv8 since eret implicitly clears the monitor. Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> Acked-by: Tim Deegan <tim@xxxxxxx> commit 47d1a51480ad0f602d747e460d619436c907deea Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Fri Jul 12 12:54:42 2013 +0100 xen: arm: make zImage the default target which we install The zImage compatible binary is the useful one on real hardware. The relocated ELF thing is only really useful when booting directly on Fast Models. The customary suffix for that case is .axf so provide that as a target. Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxxxxx> commit 2f044a6a6e4cb0ea24c856c1615e3fb878af2cfb Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Thu Jul 18 09:41:43 2013 +0100 xen: allow architecture to choose how/whether to compress installed xen binary This is a follow up to "xen: arm: make zImage the default target which we install". On ARM the xen.gz binary installed into /boot is not immediately useful because bootloaders (e.g. u-boot) do not unconditionally support decompression (except via the uImage wrapper, which we currently do not support via our build system) Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> commit 23e37f599e8bc220aca9abd097171ee17f5630ab Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Thu Jul 18 09:41:42 2013 +0100 xen: Use $(T) and $(D) aliases in install target This is consistent with the uninstall target and also shortens some longish lines. Suggested-by: Jan Beulich <jbeulich@xxxxxxxx> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> commit 524b93def23b9f75fd7851063f5291886e63d1ed Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Thu Jul 18 09:41:41 2013 +0100 xen: x86: drop the ".gz" suffix when installing As Jan says it is pretty meaningless under /boot anyway. However I am slightly concerned about breaking bootloaders (or more specifically their help scripts which automatically generate config files). By inspection at least grub 2's update-grub script (as present in Debian Wheezy) seems to cope (it matches on xen* not xen*.gz) Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> commit 09a08ef52a21d171cc48b54a975f13e7704c912f Author: Julien Grall <julien.grall@xxxxxxxxxx> Date: Thu Jul 18 14:33:43 2013 +0100 xen/arm: Implement MPIDR per VCPU Use different affinity for each VCPU and always expose an SMP systems to the guest. Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> [ ijc -- s/AFFO/AFF0/ in a comment ] commit 47193a4437f18cce75230e0fb1ca3b3c78fec7b0 Author: Eric Trudeau <etrudeau@xxxxxxxxxxxx> Date: Fri Jul 12 13:30:48 2013 -0400 xen/arm: Clear the IRQ_GUEST bit in desc->status when releasing an IRQ While adding support for guest domU IRQs, I noticed that release_irq did not clear the IRQ_GUEST bit in the IRQ's desc->status field. This is probably not a big deal since not many situations are likely to arise where an IRQ is sometimes host and sometimes guest. Signed-off-by: Eric Trudeau <etrudeau@xxxxxxxxxxxx> Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> commit 3eb214917f45e567af87605c06c28cea4208faf4 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Thu Jul 18 13:32:12 2013 +0200 VT-d: enable for multi-vector MSI The main change being to make alloc_remap_entry() capable of allocating a block of entries. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Xiantao Zhang <xiantao.zhang@xxxxxxxxx> commit e36e07bc9b0be0d899d4dd0ea675f6c225dafe5c Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Thu Jul 18 10:05:14 2013 +0200 x86: fix cache flushing condition in map_pages_to_xen() This fixes yet another shortcoming of the function (exposed by 8bfaa2c2 ["x86: add locking to map_pages_to_xen()"]'s adjustment to msix_put_fixmap()): It must not flush caches when transitioning to a non-present mapping. Doing so causes the CLFLUSH to fault, if used in favor of WBINVD. To help code readability, factor out the whole flush flags updating in map_pages_to_xen() into a helper macro. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Tested-by: Sander Eikelenboom <linux@xxxxxxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> commit 915a59f25c5eddd86bc2cae6389d0ed2ab87e69e Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Thu Jul 18 09:16:15 2013 +0200 x86/time: Update wallclock in shared info when altering domain time offset domain_set_time_offset() udpates d->time_offset_seconds, but does not correct the wallclock in the shared info, meaning that it is incorrect until the next XENPF_settime hypercall from dom0 which resynchronises the wallclock for all domains. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> (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 |