|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.3-testing test] 21989: FAIL
flight 21989 xen-4.3-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/21989/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 2 host-install(2) broken in 21984 REGR. vs. 21888 build-armhf 3 capture-logs !broken in 21984 [st=!broken!] build-armhf-pvops 2 host-install(2) broken in 21984 REGR. vs. 21888 build-armhf-pvops 3 capture-logs !broken in 21984 [st=!broken!] Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 8 guest-saverestore fail pass in 21984 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-xl 5 xen-boot fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 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-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-armhf-armhf-xl 1 xen-build-check(1) blocked in 21984 n/a test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail in 21984 never pass version targeted for testing: xen 2df9704ad1bb7484efded4fec9e81f13fab4e839 baseline version: xen be2f2316f11d56555a37873d3f53bb3f46dec856 ------------------------------------------------------------ People who touched revisions under test: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Keir Fraser <keir@xxxxxxx> Kouya Shimura <kouya@xxxxxxxxxxxxxx> Nathan Studer <nate.studer@xxxxxxxxxxxxxxx> Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx> Tim Deegan <tim@xxxxxxx> ------------------------------------------------------------ jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass 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-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-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-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-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 2df9704ad1bb7484efded4fec9e81f13fab4e839 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Nov 15 11:29:57 2013 +0100 x86: eliminate has_arch_mmios() ... as being generally insufficient: Either has_arch_pdevs() or cache_flush_permitted() should be used (in particular, it is insufficient to consider MMIO ranges alone - I/O port ranges have the same requirements if available to a guest). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: 79233938ab2a8f273fd5dcdbf8e8381b9eb3a461 master date: 2013-11-12 16:28:47 +0100 commit ec6f0183517615823641785233eeaf8372f674ac Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Nov 15 11:28:37 2013 +0100 VMX: don't crash processing 'd' debug key There's a window during scheduling where "current" and the active VMCS may disagree: The former gets set much earlier than the latter. Since both vmx_vmcs_enter() and vmx_vmcs_exit() immediately return when the subject vCPU is "current", accessing VMCS fields would, depending on whether there is any currently active VMCS, either read wrong data, or cause a crash. Going forward we might want to consider reducing the window during which vmx_vmcs_enter() might fail (e.g. doing a plain __vmptrld() when v->arch.hvm_vmx.vmcs != this_cpu(current_vmcs) but arch_vmx->active_cpu == -1), but that would add complexities (acquiring and - more importantly - properly dropping v->arch.hvm_vmx.vmcs_lock) that don't look worthwhile adding right now. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: 58929248461ecadce13e92eb5a5d9ef718a7c88e master date: 2013-11-12 11:52:19 +0100 commit 9aa5c832e967ae333caef477521d055c1c49c31e Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Nov 15 11:28:05 2013 +0100 nested SVM: adjust guest handling of structure mappings For one, nestedsvm_vmcb_map() error checking must not consist of using assertions: Global (permanent) mappings can fail, and hence failure needs to be dealt with properly. And non-global (transient) mappings can't fail anyway. And then the I/O port access bitmap handling was broken: It checked only to first of the accessed ports rather than each of them. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Christoph Egger <chegger@xxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx> master commit: b1e87805bf37b446dade93a7eb922bb7d1269756 master date: 2013-11-12 11:51:15 +0100 commit b54a623efbcf5bff25c55117add1b4427b4e2f1b Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Date: Fri Nov 15 11:27:24 2013 +0100 numa-sched: leave node-affinity alone if not in "auto" mode If the domain's NUMA node-affinity is being specified by the user/toolstack (instead of being automatically computed by Xen), we really should stick to that. This means domain_update_node_affinity() is wrong when it filters out some stuff from there even in "!auto" mode. This commit fixes that. Of course, this does not mean node-affinity is always honoured (e.g., a vcpu won't run on a pcpu of a different cpupool) but the necessary logic for taking into account all the possible situations lives in the scheduler code, where it belongs. What could happen without this change is that, under certain circumstances, the node-affinity of a domain may change when the user modifies the vcpu-affinity of the domain's vcpus. This, even if probably not a real bug, is at least something the user does not expect, so let's avoid it. Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: 67348c3ac700b8bc9147638c719c3035c5ef20f5 master date: 2013-11-12 10:54:28 +0100 commit e1c1672e9be7886dd50ddd8605855783d7d25e9b Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Nov 15 11:26:30 2013 +0100 x86/EFI: make trampoline allocation more flexible Certain UEFI implementations reserve all memory below 1Mb at boot time, making it impossible to properly allocate the chunk necessary for the trampoline. Fall back to simply grabbing a chunk from EfiBootServices* regions immediately prior to calling ExitBootServices(). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: c1f2dfe8f6a559bc28935f24e31bb33d17d9713d master date: 2013-11-08 11:08:32 +0100 commit cd766e12d4c914f3928537acb64595f5044d43bf Author: Kouya Shimura <kouya@xxxxxxxxxxxxxx> Date: Fri Nov 15 11:25:46 2013 +0100 x86/hvm: fix restart of RTC periodic timer with vpt_align=1 The commit 58afa7ef "x86/hvm: Run the RTC periodic timer on a consistent time series" aligns the RTC periodic timer to the VM's boot time. However, it's aligned later again to the system time in create_periodic_time() with vpt_align=1. The next tick might be skipped. Signed-off-by: Kouya Shimura <kouya@xxxxxxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Tim Deegan <tim@xxxxxxx> master commit: 48535f5798e3e237d9920a74c1ce3802958136c0 master date: 2013-11-08 11:07:14 +0100 commit 406323bdf652767fa2168e5ea4dfaf619d67867b Author: Nathan Studer <nate.studer@xxxxxxxxxxxxxxx> Date: Fri Nov 15 11:25:05 2013 +0100 call sched_destroy_domain before cpupool_rm_domain The domain destruction code, removes a domain from its cpupool before attempting to destroy its scheduler information. Since the scheduler framework uses the domain's cpupool information to decide on which scheduler ops to use, this results in the the wrong scheduler's destroy domain function being called when the cpupool scheduler and the initial scheduler are different. Correct this by destroying the domain's scheduling information before removing it from the pool. Signed-off-by: Nathan Studer <nate.studer@xxxxxxxxxxxxxxx> Reviewed-by: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: 117f67350fd18b11ab09d628b4edea3364b09441 master date: 2013-11-06 10:21:09 +0100 commit c179b2fd803b8b6cc29046088a90791a65d9cb32 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Nov 15 11:24:16 2013 +0100 x86/HVM: 32-bit IN result must be zero-extended to 64 bits Just like for all other operations with 32-bit operand size. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> x86/HVM: 32-bit IN result must be zero-extended to 64 bits (part 2) Just spotted a counterpart of what commit 9d89100b (same title) dealt with. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: 9d89100ba8b7b02adb7c2e89ef7c81e734942e7c master date: 2013-11-05 14:51:53 +0100 master commit: 1e521eddeb51a9f1bf0e4dd1d17efc873eafae41 master date: 2013-11-15 11:01:49 +0100 commit ff8c797392bddc04a35463958bfc2d981734d345 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Nov 15 11:23:04 2013 +0100 x86: make sure memory block is RAM before passing to the allocator Memory blocks outside of the always visible 1:1 mapping range get passed to the allocator separately (once enough other setup was done). Skipping non-RAM regions, however, was forgotten in adc5afbf ("x86: support up to 16Tb"). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: 227258983401b7e6091967ffaf22ad83f4ebaf6f master date: 2013-11-04 14:29:24 +0100 commit 53b20077f9f15cd78bad42bfdd98e27c7fe32d5e Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Nov 15 11:22:24 2013 +0100 x86/ACPI/x2APIC: guard against out of range ACPI or APIC IDs Other than for the legacy APIC, the x2APIC MADT entries have valid ranges possibly extending beyond what our internal arrays can handle, and hence we need to guard ourselves against corrupting memory here. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Keir Fraser <keir@xxxxxxx> master commit: 2c24cdcce3269f3286790c63821951a1de93c66a master date: 2013-11-04 10:10:04 +0100 commit 5c1dcf7d2c03fc9f256313cf99bfd81bddcc967d Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Nov 15 11:20:55 2013 +0100 x86: refine address validity checks before accessing page tables In commit 40d66baa ("x86: correct LDT checks") and d06a0d71 ("x86: add address validity check to guest_map_l1e()") I didn't really pay attention to the fact that these checks would better be done before the paging_mode_translate() ones, as there's also no equivalent check down the shadow code paths involved here (at least not up to the first use of the address), and such generic checks shouldn't really be done by particular backend functions anyway. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Tim Deegan <tim@xxxxxxx> master commit: 343cad8c70585c4dba8afc75e1ec1b7610605ab2 master date: 2013-10-28 12:00:36 +0100 commit 92503639bd8bedd7f9097629f77e2de5a31659b2 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Nov 15 11:20:04 2013 +0100 x86/xsave: also save/restore XCR0 across suspend (ACPI S3) Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: e47a90e6dca491c0ceea6ffa18055e7e32565e8e master date: 2013-10-21 17:26:16 +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 |