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@amd.com>
George Dunlap <george.dunlap@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Laszlo Ersek <lersek@redhat.com>
Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------
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@xen.org>
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@redhat.com>
Also, replace EEXIST with ENOSPC when failing to allocate a new
domain watchdog.
Signed-off-by: Keir Fraser <keir@xen.org>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23963:7cfd5bb3b9f9
xen-unstable date: Fri Oct 14 18:08:04 2011 +0100
changeset: 23178:849bf4ab5fe0
user: Boris Ostrovsky <boris.ostrovsky@amd.com>
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@amd.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 23925:08d6ba4e447d
xen-unstable date: Fri Oct 07 10:32:15 2011 +0200
changeset: 23177:9a38e30e5459
user: Wei Wang2 <wei.wang2@amd.com>
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@amd.com>
Committed-by: Keir Fraser <keir@xen.org>
AMD-IOMMU: remove dead variable references
These got orphaned up by recent changes.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
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@xen.org>
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@eu.citrix.com>
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@eu.citrix.com>
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@eu.citrix.com>
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@eu.citrix.com>
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@eu.citrix.com>
xen-unstable changeset: 23752:ef9ed3d2aa87
xen-unstable date: Tue Jul 26 18:36:58 2011 +0100
changeset: 23176:81e39a4978ea
user: Keir Fraser <keir@xen.org>
date: Mon Oct 24 18:03:35 2011 +0100
Revert xen-unstable:23871:503ee256fecf
Signed-off-by: Keir Fraser <keir@xen.org>
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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@amd.com>
George Dunlap <george.dunlap@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Laszlo Ersek <lersek@redhat.com>
Wei Wang2 <wei.wang2@amd.com>
------------------------------------------------------------
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@xen.org>
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@redhat.com>
Also, replace EEXIST with ENOSPC when failing to allocate a new
domain watchdog.
Signed-off-by: Keir Fraser <keir@xen.org>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23963:7cfd5bb3b9f9
xen-unstable date: Fri Oct 14 18:08:04 2011 +0100
changeset: 23178:849bf4ab5fe0
user: Boris Ostrovsky <boris.ostrovsky@amd.com>
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@amd.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 23925:08d6ba4e447d
xen-unstable date: Fri Oct 07 10:32:15 2011 +0200
changeset: 23177:9a38e30e5459
user: Wei Wang2 <wei.wang2@amd.com>
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@amd.com>
Committed-by: Keir Fraser <keir@xen.org>
AMD-IOMMU: remove dead variable references
These got orphaned up by recent changes.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
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@xen.org>
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@eu.citrix.com>
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@eu.citrix.com>
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@eu.citrix.com>
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@eu.citrix.com>
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@eu.citrix.com>
xen-unstable changeset: 23752:ef9ed3d2aa87
xen-unstable date: Tue Jul 26 18:36:58 2011 +0100
changeset: 23176:81e39a4978ea
user: Keir Fraser <keir@xen.org>
date: Mon Oct 24 18:03:35 2011 +0100
Revert xen-unstable:23871:503ee256fecf
Signed-off-by: Keir Fraser <keir@xen.org>
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel