|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.1-testing test] 9641: regressions - FAIL
flight 9641 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9641/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-sedf 7 debian-install fail REGR. vs. 9609 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass version targeted for testing: xen c33e15835e33 baseline version: xen 81e39a4978ea ------------------------------------------------------------ People who touched revisions under test: Boris Ostrovsky <boris.ostrovsky@xxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Keir Fraser <keir@xxxxxxx> Laszlo Ersek <lersek@xxxxxxxxxx> Wei Wang2 <wei.wang2@xxxxxxx> ------------------------------------------------------------ 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 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win 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. ------------------------------------------------------------ changeset: 23179:c33e15835e33 tag: tip user: Keir Fraser <keir@xxxxxxx> date: Thu Oct 27 16:24:01 2011 +0100 Return -EINVAL when trying to kick/kill a nonexistent domain watchdog ... to be more in-line with the NR_DOMAIN_WATCHDOG_TIMERS check at the top of domain_watchdog(), and also to follow the timer_(delete|settime) POSIX API's EINVAL return value. Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Also, replace EEXIST with ENOSPC when failing to allocate a new domain watchdog. Signed-off-by: Keir Fraser <keir@xxxxxxx> Committed-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 23963:7cfd5bb3b9f9 xen-unstable date: Fri Oct 14 18:08:04 2011 +0100 changeset: 23178:849bf4ab5fe0 user: Boris Ostrovsky <boris.ostrovsky@xxxxxxx> date: Thu Oct 27 16:22:53 2011 +0100 x86/AMD: Do not enable ARAT feature on AMD processors below family 0x12 Determining whether an AMD processor is affected by erratum 400 may have some corner cases and handling these cases is somewhat complicated. In the interest of simplicity we won't claim ARAT support on processor families below 0x12. Mirrors Linux commit e9cdd343a5e42c43bcda01e609fa23089e026470 Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxx> Committed-by: Jan Beulich <jbeulich@xxxxxxxx> xen-unstable changeset: 23925:08d6ba4e447d xen-unstable date: Fri Oct 07 10:32:15 2011 +0200 changeset: 23177:9a38e30e5459 user: Wei Wang2 <wei.wang2@xxxxxxx> date: Thu Oct 27 16:14:36 2011 +0100 Backport per-device vector map patches to xen 4.1.3 Recently we found an issue in xen 4.1. Under heavy I/O stress such as running bonnie++, Dom0 would lost its hard disk with lots of I/O errors. We found that some PCI-E devices was using the same vector as SMBus on AMD platforms and George' patch set that enables per-device vector map can fix this problem. 23752 xen: Infrastructure to allow irqs to share vector maps 23753 xen: Option to allow per-device vector maps for MSI IRQs 23754 xen: AMD IOMMU: Automatically enable per-device vector maps 23786 x86: Fix up irq vector map logic 23812 xen: Add global irq_vector_map option 23899 AMD-IOMMU: remove dead variable references From: Wei Wang2 <wei.wang2@xxxxxxx> Committed-by: Keir Fraser <keir@xxxxxxx> AMD-IOMMU: remove dead variable references These got orphaned up by recent changes. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 23899:a99d75671a91 xen-unstable date: Tue Oct 04 14:11:56 2011 +0200 docs: Fix 'make docs' Signed-off-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 23819:5fe770c8a8a3 xen-unstable date: Tue Sep 06 15:49:40 2011 +0100 xen: Add global irq_vector_map option, set if using AMD global intremap tables As mentioned in previous changesets, AMD IOMMU interrupt remapping tables only look at the vector, not the destination id of an interrupt. This means that all IRQs going through the same interrupt remapping table need to *not* share vectors. The irq "vector map" functionality was originally introduced after a patch which disabled global AMD IOMMUs entirely. That patch has since been reverted, meaning that AMD intremap tables can either be per-device or global. This patch therefore introduces a global irq vector map option, and enables it if we're using an AMD IOMMU with a global interrupt remapping table. This patch removes the "irq-perdev-vector-map" boolean command-line optino and replaces it with "irq_vector_map", which can have one of three values: none, global, or per-device. Setting the irq_vector_map to any value will override the default that the AMD code sets. Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> xen-unstable changeset: 23812:32814ad7458d xen-unstable date: Mon Sep 05 15:00:15 2011 +0100 x86: Fix up irq vector map logic We need to make sure that cfg->used_vector is only cleared once; otherwise there may be a race condition that allows the same vector to be assigned twice, defeating the whole purpose of the map. This makes two changes: * __clear_irq_vector() only clears the vector if the irq is not being moved * smp_iqr_move_cleanup_interrupt() only clears used_vector if this is the last place it's being used (move_cleanup_count==0 after decrement). Also make use of asserts more consistent, to catch this kind of logic bug in the future. Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> xen-unstable changeset: 23786:3a05da2dc7c0 xen-unstable date: Mon Aug 22 16:15:33 2011 +0100 xen: AMD IOMMU: Automatically enable per-device vector maps Automatically enable per-device vector maps when using IOMMU, unless disabled specifically by an IOMMU parameter. Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> xen-unstable changeset: 23754:fa4e2ca9ecff xen-unstable date: Tue Jul 26 18:37:32 2011 +0100 xen: Option to allow per-device vector maps for MSI IRQs Add a vector-map to pci_dev, and add an option to point MSI-related IRQs to the vector-map of the device. This prevents irqs from the same device from being assigned the same vector on different pcpus. This is required for systems using an AMD IOMMU, since the intremap tables on AMD only look at vector, and not destination ID. Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> xen-unstable changeset: 23753:2e0cf9428554 xen-unstable date: Tue Jul 26 18:37:16 2011 +0100 xen: Infrastructure to allow irqs to share vector maps Laying the groundwork for per-device vector maps. This generic code allows any irq to point to a vector map; all irqs sharing the same vector map will avoid sharing vectors. Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> xen-unstable changeset: 23752:ef9ed3d2aa87 xen-unstable date: Tue Jul 26 18:36:58 2011 +0100 changeset: 23176:81e39a4978ea user: Keir Fraser <keir@xxxxxxx> date: Mon Oct 24 18:03:35 2011 +0100 Revert xen-unstable:23871:503ee256fecf Signed-off-by: Keir Fraser <keir@xxxxxxx> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |