[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.2-testing test] 17601: regressions - FAIL
flight 17601 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/17601/ 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. 17481 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail like 17481 Tests which did not succeed, but are not blocking: build-armhf 4 xen-build fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xl-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 never pass test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xend-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-i386-i386-xl-qemut-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail never pass version targeted for testing: xen 0984c2b63a7c3e9dfa770b29dac51a5124aecaab baseline version: xen 2bebeac00164b8fd6fdc98db74df943d927aab06 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Ben Guthro <benjamin.guthro@xxxxxxxxxx> Dongxiao Xu <dongxiao.xu@xxxxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Keir Fraser <keir@xxxxxxx> Stefan Bader <stefan.bader@xxxxxxxxxxxxx> Tim Deegan <tim@xxxxxxx> ------------------------------------------------------------ jobs: build-amd64 pass build-armhf fail build-i386 pass build-amd64-oldkern pass build-i386-oldkern fail build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-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-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 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-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass 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-i386-i386-xl-qemut-winxpsp3 fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-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 0984c2b63a7c3e9dfa770b29dac51a5124aecaab Author: Tim Deegan <tim@xxxxxxx> Date: Tue Apr 9 16:07:23 2013 +0200 x86/mm/shadow: spurious warning when unmapping xenheap pages. Xenheap pages will always have an extra typecount, taken in share_xen_page_with_guest(), which doesn't come from a shadow PTE. Adjust the warning in sh_remove_all_mappings() to account for it. Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Signed-off-by: Tim Deegan <tim@xxxxxxx> Tested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: cfc515dabe91e3d6c690c68c6a669d6d77fb7ac4 master date: 2013-04-04 10:14:30 +0100 commit d5483523365e85c324d06e8e2b025829aae95f41 Author: Stefan Bader <stefan.bader@xxxxxxxxxxxxx> Date: Tue Apr 9 16:06:44 2013 +0200 VMX: Always disable SMEP when guest is in non-paging mode commit e7dda8ec9fc9020e4f53345cdbb18a2e82e54a65 VMX: disable SMEP feature when guest is in non-paging mode disabled the SMEP bit if a guest VCPU was using HAP and was not in paging mode. However I could observe VCPUs getting stuck in the trampoline after the following patch in the Linux kernel changed the way CR4 gets set up: x86, realmode: read cr4 and EFER from kernel for 64-bit trampoline The change will set CR4 from already set flags which includes the SMEP bit. On bare metal this does not matter as the CPU is in non- paging mode at that time. But Xen seems to use the emulated non- paging mode regardless of HAP (I verified that on the guests I was seeing the issue, HAP was not used). Therefor it seems right to unset the SMEP bit for a VCPU that is not in paging-mode, regardless of its HAP usage. Signed-off-by: Stefan Bader <stefan.bader@xxxxxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> Acked-by: Dongxiao Xu <dongxiao.xu@xxxxxxxxx> master commit: 0d2e673a763bc7c2ddf97fed074eb691d325ecc5 master date: 2013-04-04 10:37:19 +0200 commit 77cb78851429a5a8509e3dfed466b2580ad5c60d Author: Ben Guthro <benjamin.guthro@xxxxxxxxxx> Date: Tue Apr 9 16:05:52 2013 +0200 x86/S3: Restore broken vcpu affinity on resume When in SYS_STATE_suspend, and going through the cpu_disable_scheduler path, save a copy of the current cpu affinity, and mark a flag to restore it later. Later, in the resume process, when enabling nonboot cpus restore these affinities. Signed-off-by: Ben Guthro <benjamin.guthro@xxxxxxxxxx> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: 41e71c2607e036f1ac00df898b8f4acb2d4df7ee master date: 2013-04-02 09:52:32 +0200 commit 5da556675105169807ae2bfe232a2cc4c3f2ae1e Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Apr 9 16:04:25 2013 +0200 x86: irq_move_cleanup_interrupt() must ignore legacy vectors Since the main loop in the function includes legacy vectors, and since vector_irq[] gets set up for legacy vectors regardless of whether those get handled through the IO-APIC, it must not do anything on this vector range. In fact, we should never get past the move_cleanup_count check for IRQs not handled through the IO-APIC. Adding a respective assertion woulkd make those iterations more expensive (due to the lock acquire). For such an assertion to not have false positives we however ought to suppress setting up IRQ2 as an 8259A interrupt (which wasn't correct anyway), which is being done here despite the assertion not actually getting added. Furthermore, there's no point iterating over the vectors past LAST_HIPRIORITY_VECTOR, so terminate the loop accordingly. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: af699220ad6d111ba76fc3040342184e423cc9a1 master date: 2013-04-02 08:30:03 +0200 (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 |