|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.1-testing test] 18158: regressions - FAIL
flight 18158 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/18158/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-win7-amd64 7 windows-install fail REGR. vs. 18141 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-xend-qemut-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop fail never pass test-i386-i386-xl-qemut-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass version targeted for testing: xen 8b94e436ed3f83e899f5b0cc403461f95750964b baseline version: xen ac63ddd70a5ccf5ebf790f06ea4cd4ed794c3978 ------------------------------------------------------------ People who touched revisions under test: Aravindh Puthiyaparambil <aravindp@xxxxxxxxx> Christoph Egger <chegger@xxxxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Keir Fraser <keir@xxxxxxx> Roger Pau Monné <roger.pau@xxxxxxxxxx> ------------------------------------------------------------ jobs: build-amd64 pass build-armhf fail build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass 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 8b94e436ed3f83e899f5b0cc403461f95750964b Author: Roger Pau Monné <roger.pau@xxxxxxxxxx> Date: Mon Jun 17 11:12:41 2013 +0200 x86/vtsc: update vcpu_time in hvm_set_guest_time When using a vtsc, hvm_set_guest_time changes hvm_vcpu.stime_offset, which is used in the vcpu time structure to calculate the tsc_timestamp, so after updating stime_offset we need to propagate the change to vcpu_time in order for the guest to get the right time if using the PV clock. Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> master commit: 32c864a35ece2c24a336d183869a546798a4b241 master date: 2013-06-05 10:03:08 +0200 commit 455a677fbfbfca0dcb985f0ae485437483787347 Author: Aravindh Puthiyaparambil <aravindp@xxxxxxxxx> Date: Mon Jun 17 11:12:06 2013 +0200 x86/MCE: disable if MCE banks are not present When booting Xen on VMware ESX 5.1 and Workstation 9, you hit a GPF during MCE initialization. The culprit is line 631 in set_poll_bankmask(): bitmap_copy(mb->bank_map, mca_allbanks->bank_map, nr_mce_banks); What is happening is that in mca_cap_init(), nr_mce_banks is being set to 0. This causes the allocation of bank_map to be set to ZERO_BLOCK_PTR which is the return value for zero-size allocation by xzalloc_array()/_xmalloc(). This results in the bitmap_copy() to fail disastrously. The following patch fixes this issue. Signed-off-by: Aravindh Puthiyaparambil <aravindp@xxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Christoph Egger <chegger@xxxxxxxxx> master commit: 5cffb77c4072fa5b46700a2dbb3e46c5a54eba6d master date: 2013-06-03 15:42:46 +0200 commit df751b6da15afff1f87a68f63013dd96e9563047 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Jun 17 11:09:09 2013 +0200 x86: fix ordering of operations in destroy_irq() The fix for XSA-36, switching the default of vector map management to be per-device, exposed more readily a problem with the cleanup of these vector maps: dynamic_irq_cleanup() clearing desc->arch.used_vectors keeps the subsequently invoked clear_irq_vector() from clearing the bits for both the in-use and a possibly still outstanding old vector. Fix this by folding dynamic_irq_cleanup() into destroy_irq(), which was its only caller, deferring the clearing of the vector map pointer until after clear_irq_vector(). Once at it, also defer resetting of desc->handler until after the loop around smp_mb() checking for IRQ_INPROGRESS to be clear, fixing a (mostly theoretical) issue with the intercation with do_IRQ(): If we don't defer the pointer reset, do_IRQ() could, for non-guest IRQs, call ->ack() and ->end() with different ->handler pointers, potentially leading to an IRQ remaining un-acked. The issue is mostly theoretical because non-guest IRQs are subject to destroy_irq() only on (boot time) error paths. As to the changed locking: Invoking clear_irq_vector() with desc->lock held is okay because vector_lock already nests inside desc->lock (proven by set_desc_affinity(), which takes vector_lock and gets called from various desc->handler->ack implementations, getting invoked with desc->lock held). Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> master commit: 43427e65ccfea0c6dc0232f358287e6cc616b507 master date: 2013-05-31 08:35:22 +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 |