|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.2-testing test] 25500: regressions - FAIL
flight 25500 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/25500/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 25152 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 17 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-i386-i386-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-i386-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check fail never pass test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen ea3db636df531428320e6ab61479731be283ac23 baseline version: xen 0620cc886eef9018d2b2a5fcdc641be70b5ac54b ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Dongxiao Xu <dongxiao.xu@xxxxxxxxx> Frediano Ziglio <frediano.ziglio@xxxxxxxxxx> Ian Campbell <Ian.Campbell@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Keir Fraser <keir@xxxxxxx> Xiantao Zhang <xiantao.zhang@xxxxxxxxx> ------------------------------------------------------------ jobs: build-amd64 pass 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-i386-qemuu-freebsd10-amd64 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-i386-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-i386-qemuu-freebsd10-i386 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-qemuu-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 osstest.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 ea3db636df531428320e6ab61479731be283ac23 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Mar 14 17:52:27 2014 +0100 x86/HVM: consolidate passthrough handling in epte_get_entry_emt() It is inconsistent to depend on iommu_enabled alone: For a guest without devices passed through to it, it is of no concern whether the IOMMU is enabled. There's one rather special case to take care of: VMX code marks the LAPIC access page as MMIO. The added assertion needs to take this into consideration, and the subsequent handling of the direct MMIO case was inconsistent too: That page would have been WB in the absence of an IOMMU, but UC in the presence of it, while in fact the cachabilty of this page is entirely unrelated to an IOMMU being in use. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: 3089a6d82bdf3112ccb1dd074ce34a8cbdc4ccd8 master date: 2014-03-10 11:04:36 +0100 commit 1df316f038151cb23350337b6e1ee1a94fb4f9d8 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Mar 14 17:51:39 2014 +0100 x86/HVM: fix memory type merging in epte_get_entry_emt() Using the minimum numeric value of guest and host specified memory types is too simplistic - it works only correctly for a subset of types. It is in particular the WT/WP combination that needs conversion to UC if the two types conflict. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: b99113b9d5fac5149de8496f55afa00e285b1ff3 master date: 2014-03-10 11:03:53 +0100 commit 999d56f527282399b68592635e55625fbf9b94d7 Author: Dongxiao Xu <dongxiao.xu@xxxxxxxxx> Date: Fri Mar 14 17:51:07 2014 +0100 x86/hvm: refine the judgment on IDENT_PT for EMT When trying to get the EPT EMT type, the judgment on HVM_PARAM_IDENT_PT is not correct which always returns WB type if the parameter is not set. Remove the related code. Signed-off-by: Dongxiao Xu <dongxiao.xu@xxxxxxxxx> We can't fully drop the dependency yet, but we should certainly avoid overriding cases already properly handled. The reason for this is that the guest setting up its MTRRs happens _after_ the EPT tables got already constructed, and no code is in place to propagate this to the EPT code. Without this check we're forcing the guest to run with all of its memory uncachable until something happens to re-write every single EPT entry. But of course this has to be just a temporary solution. In the same spirit we should defer the "very early" (when the guest is still being constructed and has no vCPU yet) override to the last possible point. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: cadfd7bca999c0a795dc27be72d43c92e8943a0b master date: 2014-03-10 11:02:25 +0100 commit 83a20cab51bbedf48d45ca662cbde0a63f57fbb7 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Mar 14 17:50:03 2014 +0100 IOMMU: generalize and correct softirq processing during Dom0 device setup c/s 21039:95f5a4ce8f24 ("VT-d: reduce default verbosity") having put a call to process_pending_softirqs() in VT-d's domain_context_mapping() was wrong in two ways: For one we shouldn't be doing this when setting up a device during DomU assignment. And then - I didn't check whether that was the case already back then - we shouldn't call that function with the pcidevs_lock (or in fact any spin lock) held. Move the "preemption" into generic code, at once dealing with further actual (too much output elsewhere - particularly on systems with very many host bridge like devices - having been observed to still cause the watchdog to trigger when enabled) and potential (other IOMMU code may also end up being too verbose) issues. Do the "preemption" once per device actually being set up when in verbose mode, and once per bus otherwise. Note that dropping pcidevs_lock around the process_pending_softirqs() invocation is specifically not a problem here: We're in an __init function and aren't racing with potential additions/removals of PCI devices. Not acquiring the lock in setup_dom0_pci_devices() otoh is not an option, as there are too many places that assert the lock being held. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Xiantao Zhang <xiantao.zhang@xxxxxxxxx> master commit: 9ef5aa944a6a0df7f5938983043c7e46f158bbc6 master date: 2014-03-04 10:52:20 +0100 commit d404af9ba05389a43de8cf56e6c174bfb86db62e Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Mar 14 17:45:52 2014 +0100 x86/mce: Reduce boot-time logspam When booting with "no-mce", the user does not need to be told that "MCE support [was] disabled by bootparam" for each cpu. Furthermore, a file:line reference is unnecessary. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: a5ab9c9fa29cda7e1b18dbcaa69a5dbded96de32 master date: 2014-02-25 09:30:59 +0100 commit f4c6912c95ed5d5bb08e1b07b9588876595ecdbd Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Mar 14 17:45:14 2014 +0100 x86/MSI: don't risk division by zero The check in question is redundant with the one in the immediately following if(), where dividing by zero gets carefully avoided. Spotted-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> master commit: 5d160d913e03b581bdddde73535c18ac670cf0a9 master date: 2014-02-24 12:11:01 +0100 commit ea3ec32f7956917eb0339b2b0df24e8f658a05ed Author: Frediano Ziglio <frediano.ziglio@xxxxxxxxxx> Date: Fri Mar 14 17:44:19 2014 +0100 x86/MCE: Fix race condition in mctelem_reserve These lines (in mctelem_reserve) newhead = oldhead->mcte_next; if (cmpxchgptr(freelp, oldhead, newhead) == oldhead) { are racy. After you read the newhead pointer it can happen that another flow (thread or recursive invocation) change all the list but set head with same value. So oldhead is the same as *freelp but you are setting a new head that could point to whatever element (even already used). This patch use instead a bit array and atomic bit operations. Signed-off-by: Frediano Ziglio <frediano.ziglio@xxxxxxxxxx> Reviewed-by: Liu Jinsong <jinsong.liu@xxxxxxxxx> master commit: 60ea3a3ac3d2bcd8e85b250fdbfc46b3b9dc7085 master date: 2014-02-24 12:07:41 +0100 commit fa669779b4a9d07d35a9708ac97d2c98063c29b1 Author: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Date: Fri Mar 14 17:43:15 2014 +0100 x86/pci: Store VF's memory space displacement in a 64-bit value VF's memory space offset can be greater than 4GB and therefore needs to be stored in a 64-bit variable. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> master commit: 001bdcee7bc19be3e047d227b4d940c04972eb02 master date: 2014-02-13 10:49:55 +0100 commit 50d989262d136b7a5a602c80681705ac6cfe95a8 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Jan 7 10:04:23 2014 +0000 tools/libxc: Correct read_exact() error messages The errors have been incorrectly identifying their function since c/s 861aef6e1558bebad8fc60c1c723f0706fd3ed87 which did a lot of error handling cleanup. Use __func__ to ensure the name remains correct in the future. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Ian Campbell <Ian.Campbell@xxxxxxxxxx> CC: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> (cherry picked from commit 1671cdeac7da663fb2963f3e587fa279dcd0238b) (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 |