[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable test] 17402: regressions - FAIL
flight 17402 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/17402/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-win7-amd64 10 guest-saverestore.2 fail REGR. vs. 17399 build-amd64-oldkern 4 xen-build fail REGR. vs. 17399 build-i386-oldkern 4 xen-build fail REGR. vs. 17399 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-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-qemuu-winxpsp3 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-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail never pass version targeted for testing: xen 6890cebc6a987d0e896f5d23a8de11a3934101cf baseline version: xen 72af01bf6f7489e54ad59270222a29d3e8c501d1 ------------------------------------------------------------ People who touched revisions under test: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Dr. Greg Wettstein <greg@xxxxxxxxxxxx> Fabio Fantoni <fabio.fantoni@xxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxxxxx> Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Malcolm Crossley <malcolm.crossley@xxxxxxxxxx> Marcus Granado <marcus.granado@xxxxxxxxxx> Wei Liu <wei.liu2@xxxxxxxxxx> ------------------------------------------------------------ jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-oldkern fail build-i386-oldkern fail build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass 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 6890cebc6a987d0e896f5d23a8de11a3934101cf Author: Malcolm Crossley <malcolm.crossley@xxxxxxxxxx> Date: Mon Mar 25 14:31:27 2013 +0100 VT-d: deal with 5500/5520/X58 errata http://www.intel.com/content/www/us/en/chipsets/5520-and-5500-chipset-ioh-specification-update.html Stepping B-3 has two errata (#47 and #53) related to Interrupt remapping, to which the workaround is for the BIOS to completely disable interrupt remapping. These errata are fixed in stepping C-2. Unfortunately this chipset stepping is very common and many BIOSes are not disabling interrupt remapping on this stepping . We can detect this in Xen and prevent Xen from using the problematic interrupt remapping feature. The Intel 5500/5520/X58 chipset does not support VT-d Extended Interrupt Mode(EIM). This means the iommu_supports_eim() check always fails and so x2apic mode cannot be enabled in Xen before this quirk disables the interrupt remapping feature. Signed-off-by: Malcolm Crossley <malcolm.crossley@xxxxxxxxxx> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Gate the function call to check the quirk on interrupt remapping being requested to get enabled, and upon failure disable the IOMMU to be in line with what the changes for XSA-36 (plus follow-ups) did. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx> commit fae0372140befb88d890a30704a8ec058c902af8 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Mar 25 14:28:31 2013 +0100 IOMMU: properly check whether interrupt remapping is enabled ... rather than the IOMMU as a whole. That in turn required to make sure iommu_intremap gets properly cleared when the respective initialization fails (or isn't being done at all). Along with making sure interrupt remapping doesn't get inconsistently enabled on some IOMMUs and not on others in the VT-d code, this in turn allowed quite a bit of cleanup on the VT-d side (if desired, that cleanup could of course be broken out into a separate patch). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx> commit 85bae8b3406b234f3074617771072623525a3576 Author: Wei Liu <wei.liu2@xxxxxxxxxx> Date: Tue Mar 19 17:45:49 2013 +0000 xenconsoled: use array index to keep track of pollfd If we use pointers to reference elements inside array, it is possible that we get wild pointer after realloc(3) copies array and returns a new pointer. Keep track of element indexes inside the array can solve this problem. Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Marcus Granado <marcus.granado@xxxxxxxxxx> Tested-by: Marcus Granado <marcus.granado@xxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> commit f325cdf4118a3209d4c193b9490bd5bc8f2150fb Author: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Date: Mon Mar 11 13:57:47 2013 +0000 libxl: Streamline vnc argument generation code Makes the following changes to the vnc generation code: * Simplifies and comments it, making it easier to read and grok * Throws an error if duplicate values of display are set, rather than the current very un-intuitive behavior. Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> commit 6cffb2b469a55032a2900ccb8776c0082f346758 Author: Dr. Greg Wettstein <greg@xxxxxxxxxxxxxxxxx> Date: Tue Mar 19 07:26:33 2013 +0000 tools: Retry blktap2 tapdisk message on interrupt. Re-start blktap2 IPC select call on interrupt. We hunted this miserable bug for a long time. The teardown of a blktap2 tapdisk instance is being carried out inconsistently up to and including the 4.2.1 release. The problem appears to be a classic 'Heisenbug' which disappears if a single function call is added to the tapdisk shutdown path. It is likely this bug has been in existence for the life of the blktap2 code. Control messages to manipulate a tapdisk instance are sent over a UNIX domain socket. A select call is used on both the read and write paths to wait on I/O and to set a timeout for the transmission and reception of the control plane messages. The existing code fails receipt or transmission of the control message on any type of error return from the select call. The xl control process receives an interrupt while waiting in the select call which in turn causes an error return with SIGINT as the return code. This prematurely terminates the teardown of the tapdisk instance leaving it in various states of shutdown. Since multiple messages are needed to implement a full teardown the tapdisk instance can be left in various states ranging from fully connected to only the minor being left allocated. The fix is straight forward. Check the return code from the select call and re-try read or write of the control message if errno is sent to EINTR. The problem manifests itself in the read path but there appears to be little reason to not add the fix to the write path as well. Both paths appear to be cut-and-paste copies of each other. Signed-off-by: Dr. Greg Wettstein <greg@xxxxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> commit 753d16c1d0d5e194546de1a9f67034d3e6576844 Author: fantonifabio@xxxxxxxxxx <fantonifabio@xxxxxxxxxx> Date: Mon Mar 18 10:59:53 2013 +0000 tools/firmware: Fix ovmf build with gcc version different from 4.4 Signed-off-by: Fabio Fantoni <fabio.fantoni@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 |