flight 9085 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9085/
Regressions :-(
Tests which did not succeed and are blocking:
test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995
Tests which are failing intermittently (not blocking):
test-amd64-i386-pv 5 xen-boot fail pass in 9083
test-amd64-amd64-xl 5 xen-boot fail pass in 9083
test-amd64-amd64-pv 5 xen-boot fail pass in 9083
test-amd64-i386-xl 5 xen-boot fail pass in 9083
test-amd64-i386-rhel6hvm-intel 7 redhat-install fail pass in 9083
test-amd64-amd64-xl-sedf 5 xen-boot fail pass in 9083
test-i386-i386-xl-win 5 xen-boot fail pass in 9083
test-amd64-i386-xl-win-vcpus1 5 xen-boot fail pass in 9081
test-i386-i386-win 5 xen-boot fail pass in 9083
test-amd64-i386-win-vcpus1 5 xen-boot fail pass in 9079
test-amd64-i386-win 5 xen-boot fail pass in 9079
test-amd64-i386-xl-multivcpu 5 xen-boot fail in 9083 pass in 9085
test-amd64-i386-xl-credit2 5 xen-boot fail in 9083 pass in 9085
test-i386-i386-xl 5 xen-boot fail in 9083 pass in 9085
test-amd64-i386-pair 7 xen-boot/src_host fail in 9083 pass in 9085
test-amd64-i386-pair 8 xen-boot/dst_host fail in 9083 pass in 9085
test-amd64-amd64-win 5 xen-boot fail in 9083 pass in 9085
test-amd64-amd64-xl-win 5 xen-boot fail in 9083 pass in 9085
test-i386-i386-pv 5 xen-boot fail in 9081 pass in 9085
test-amd64-amd64-xl-sedf 7 debian-install fail in 9081 pass in 9083
test-i386-i386-pair 7 xen-boot/src_host fail in 9079 pass in 9085
test-i386-i386-pair 8 xen-boot/dst_host fail in 9079 pass in 9085
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-amd64-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-win 13 guest-stop fail never pass
test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail in 9083 never pass
test-i386-i386-xl-win 13 guest-stop fail in 9083 never pass
test-i386-i386-win 16 leak-check/check fail in 9083 never pass
test-amd64-i386-xl-win-vcpus1 13 guest-stop fail in 9081 never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail in 9079 never pass
test-amd64-i386-win 16 leak-check/check fail in 9079 never pass
version targeted for testing:
xen cc339ab1d917
baseline version:
xen a422e2a4451e
------------------------------------------------------------
People who touched revisions under test:
Andreas Herrmann <herrmann.der.user@googlemail.com>
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Lasse Collin <lasse.collin@tukaani.org>
Olaf Hering <olaf@aepfle.de>
Thomas Renninger <trenn@suse.de>
------------------------------------------------------------
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 fail
test-amd64-i386-xl fail
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 fail
test-amd64-i386-pv fail
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: 23872:cc339ab1d917
tag: tip
user: Ian Campbell <ian.campbell@citrix.com>
date: Thu Sep 22 18:37:06 2011 +0100
tools: fix install of lomount
$(BIN) went away in 23124:e3d4c34b14a3.
Also there are no *.so, *.a or *.rpm built in here
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
changeset: 23871:503ee256fecf
user: Jan Beulich <jbeulich@suse.com>
date: Thu Sep 22 18:35:30 2011 +0100
x86: ucode-amd: Don''t warn when no ucode is available for a CPU
revision
This patch originally comes from the Linus mainline kernel (2.6.33),
find below the patch details:
From: Andreas Herrmann <herrmann.der.user@googlemail.com>
There is no point in warning when there is no ucode available
for a specific CPU revision. Currently the container-file, which
provides the AMD ucode patches for OS load, contains only a few
ucode patches.
It''s already clearly indicated by the printed patch_level
whenever new ucode was available and an update happened. So the
warning message is of no help but rather annoying on systems
with many CPUs.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
changeset: 23870:5c97b02f48fc
user: Jan Beulich <jbeulich@suse.com>
date: Thu Sep 22 18:34:27 2011 +0100
XZ: Fix incorrect XZ_BUF_ERROR
From: Lasse Collin <lasse.collin@tukaani.org>
xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the
following was true:
- The caller knows how many bytes of output to expect and only
provides
that much output space.
- When the last output bytes are decoded, the caller-provided input
buffer ends right before the LZMA2 end of payload marker. So LZMA2
won''t provide more output anymore, but it won''t know it
yet and
thus
won''t return XZ_STREAM_END yet.
- A BCJ filter is in use and it hasn''t left any unfiltered bytes
in
the
temp buffer. This can happen with any BCJ filter, but in practice
it''s more likely with filters other than the x86 BCJ.
This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408>
where Squashfs thinks that a valid file system is corrupt.
This also fixes a similar bug in single-call mode where the
uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller
provided no output space. Many empty .xz files don''t contain any
blocks and thus don''t trigger this bug.
This also tweaks a closely related detail: xz_dec_bcj_run() could call
xz_dec_lzma2_run() to decode into temp buffer when it was known to be
useless. This was harmless although it wasted a minuscule number of
CPU cycles.
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
changeset: 23869:db1ea4b127cd
user: Jan Beulich <jbeulich@suse.com>
date: Thu Sep 22 18:33:48 2011 +0100
XZ decompressor: Fix decoding of empty LZMA2 streams
From: Lasse Collin <lasse.collin@tukaani.org>
The old code considered valid empty LZMA2 streams to be corrupt.
Note that a typical empty .xz file has no LZMA2 data at all,
and thus most .xz files having no uncompressed data are handled
correctly even without this fix.
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
changeset: 23868:28147fd781af
user: Jan Beulich <jbeulich@suse.com>
date: Thu Sep 22 18:32:34 2011 +0100
VT-d: fix off-by-one error in RMRR validation
(base_addr,end_addr) is an inclusive range, and hence there
shouldn''t
be a subtraction of 1 in the second invocation of page_is_ram_type().
For RMRRs covering a single page that actually resulted in the
immediately preceding page to get checked (which could have resulted
in a false warning).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
changeset: 23867:571b6e90dfb4
user: Jan Beulich <jbeulich@suse.com>
date: Thu Sep 22 18:31:44 2011 +0100
VT-d: eliminate a mis-use of pcidevs_lock
dma_pte_clear_one() shouldn''t acquire this global lock for the
purpose
of processing a per-domain list. Furthermore the function a few lines
earlier has a comment stating that acquiring pcidevs_lock isn''t
necessary here (whether that''s really correct is another question).
Use the domain''s mappin_lock instead to protect the mapped_rmrrs
list.
Fold domain_rmrr_mapped() into its sole caller so that the otherwise
implicit dependency on pcidevs_lock there becomes more obvious (see
the comment there).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
changeset: 23866:47ec1d405af9
user: Jan Beulich <jbeulich@suse.com>
date: Thu Sep 22 18:31:02 2011 +0100
x86: IO-APIC code has no dependency on PCI
The IRQ handling code requires pcidevs_lock to be held only for MSI
interrupts.
As the handling of which was now fully moved into msi.c (i.e. while
applying fine without, the patch needs to be applied after the one
titled "x86: split MSI IRQ chip"), io_apic.c now also
doesn''t need to
include PCI headers anymore.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
changeset: 23865:d6e01c7853cf
user: Jan Beulich <jbeulich@suse.com>
date: Thu Sep 22 18:29:19 2011 +0100
PCI multi-seg: config space accessor adjustments
Signed-off-by: Jan Beulich <jbeulich@suse.com>
changeset: 23864:314b147d524d
user: Jan Beulich <jbeulich@suse.com>
date: Thu Sep 22 18:28:38 2011 +0100
PCI multi-seg: Pass-through adjustments
Signed-off-by: Jan Beulich <jbeulich@suse.com>
changeset: 23863:9e0259239822
user: Jan Beulich <jbeulich@suse.com>
date: Thu Sep 22 18:28:03 2011 +0100
PCI multi-seg: AMD-IOMMU specific adjustments
There are two places here where it is entirely unclear to me where the
necessary PCI segment number should be taken from (as IVMD descriptors
don''t have such, only IVHD ones do). AMD confirmed that for the
time
being it is acceptable to imply that only segment 0 exists.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
changeset: 23862:85418e168527
user: Jan Beulich <jbeulich@suse.com>
date: Thu Sep 22 18:27:26 2011 +0100
PCI multi-seg: VT-d specific adjustments
Signed-off-by: Jan Beulich <jbeulich@suse.com>
changeset: 23861:ec7c81fbe0de
user: Jan Beulich <jbeulich@suse.com>
date: Thu Sep 22 18:26:54 2011 +0100
PCI multi-seg: adjust domctl interface
Again, a couple of directly related functions at once get adjusted to
account for the segment number.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
changeset: 23860:a422e2a4451e
user: Jan Beulich <jbeulich@suse.com>
date: Sun Sep 18 00:26:52 2011 +0100
x86: split MSI IRQ chip
With the .end() accessor having become optional and noting that
several of the accessors'' behavior really depends on the result of
msi_maskable_irq(), the splits the MSI IRQ chip type into two - one
for the maskable ones, and the other for the (MSI only) non-maskable
ones.
At once the implementation of those methods gets moved from io_apic.c
to msi.c.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
=======================================commit
cd776ee9408ff127f934a707c1a339ee600bc127
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue Jun 28 13:50:53 2011 +0100
qemu-char.c: fix incorrect CONFIG_STUBDOM handling
qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined
[-Wundef]
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Jackson
2011-Sep-27 12:37 UTC
[Xen-devel] Re: [xen-unstable test] 9085: regressions - FAIL
xen.org writes ("[xen-unstable test] 9085: regressions -
FAIL"):> test-amd64-i386-xl 5 xen-boot fail pass in 9083
Boot failure on machines with AMD IOMMU, I think.
Ian.
Sep 26 12:13:59.207009 (XEN) PCI: Using MCFG for segment 0000 bus 00-ff
Sep 26 12:13:59.214606 (XEN) Xen BUG at iommu_init.c:777
Sep 26 12:13:59.218999 (XEN) ----[ Xen-4.2-unstable x86_64 debug=y Not
tainted ]----
Sep 26 12:13:59.226620 (XEN) CPU: 0
Sep 26 12:13:59.226659 (XEN) RIP: e008:[<ffff82c48026f576>]
alloc_ivrs_mappings+0x14/0x18b
Sep 26 12:13:59.235021 (XEN) RFLAGS: 0000000000010246 CONTEXT: hypervisor
Sep 26 12:13:59.243013 (XEN) rax: 0000000000000000 rbx: ffff8302155faee0
rcx: 0000000000000000
Sep 26 12:13:59.250624 (XEN) rdx: 0000000000000000 rsi: 0000000000000010
rdi: 0000000000000000
Sep 26 12:13:59.259027 (XEN) rbp: ffff82c4802a7d58 rsp: ffff82c4802a7d48 r8:
ffff83021b202004
Sep 26 12:13:59.266626 (XEN) r9: 0000000000000010 r10: 0000000000000004
r11: 0000000000000001
Sep 26 12:13:59.274671 (XEN) r12: 0000000000000000 r13: ffff82c3ffd7a620
r14: ffff82c3ffd7a620
Sep 26 12:13:59.282628 (XEN) r15: ffff83000007bfb0 cr0: 000000008005003b
cr4: 00000000000006f0
Sep 26 12:13:59.290627 (XEN) cr3: 00000000dfcac000 cr2: 0000000000000000
Sep 26 12:13:59.295026 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss:
0000 cs: e008
Sep 26 12:13:59.303027 (XEN) Xen stack trace from rsp=ffff82c4802a7d48:
Sep 26 12:13:59.310613 (XEN) ffff8302155faee0 ffff82c3ffd7a650
ffff82c4802a7da8 ffff82c480270508
Sep 26 12:13:59.318631 (XEN) ffff82c4802a7df0 ffff83000007bf30
ffff82c4802a7d98 0000000000000030
Sep 26 12:13:59.326629 (XEN) ffff82c3ffd7a650 ffff82c3ffd7a620
ffff82c3ffd7a620 ffff83000007bfb0
Sep 26 12:13:59.334630 (XEN) ffff82c4802a7dd8 ffff82c480271f5f
ffff82c480271ebc ffff82c48028adbd
Sep 26 12:13:59.342631 (XEN) ffff83000007bf30 ffff83000007bf30
ffff82c4802a7e08 ffff82c48027238b
Sep 26 12:13:59.350631 (XEN) ffff8302155faea0 ffff82c3ffd7a620
00000000ffffffed 0000000000000000
Sep 26 12:13:59.359035 (XEN) ffff82c4802a7e18 ffff82c4802707df
ffff82c4802a7e28 ffff82c48026ff9b
Sep 26 12:13:59.366656 (XEN) ffff82c4802a7e48 ffff82c48026cfc7
ffff82c4802a7f18 ffff83000007bfb0
Sep 26 12:13:59.374634 (XEN) ffff82c4802a7f08 ffff82c48027e179
0000000000000000 0000000000000000
Sep 26 12:13:59.382632 (XEN) ffff83000007bdc0 000000000084a000
00000000dfa00000 0000000000000000
Sep 26 12:13:59.390632 (XEN) 00000000002f6280 ffff82c4802d9574
ffff83000007bf30 00000000ffffffff
Sep 26 12:13:59.399033 (XEN) ffff82c400000004 ffff830000000003
0000000800000000 000000010000006e
Sep 26 12:13:59.406634 (XEN) 0000000000000003 00000000000002f8
0000000000000000 0000000000000000
Sep 26 12:13:59.414634 (XEN) 0000000000000000 0000000000000000
0000000000000000 0000000000000000
Sep 26 12:13:59.422635 (XEN) 000000000007fe0c ffff82c4801000b5
0000000000000000 0000000000000000
Sep 26 12:13:59.430737 (XEN) 0000000000000000 0000000000000000
0000000000000000 0000000000000000
Sep 26 12:13:59.442655 (XEN) 0000000000000000 0000000000000000
0000000000000000 0000000000000000
Sep 26 12:13:59.451039 (XEN) 0000000000000000 0000000000000000
0000000000000000 0000000000000000
Sep 26 12:13:59.458638 (XEN) 0000000000000000 0000000000000000
0000000000000000 0000000000000000
Sep 26 12:13:59.466638 (XEN) 0000000000000000 0000000000000000
0000000000000000 0000000000000000
Sep 26 12:13:59.474638 (XEN) Xen call trace:
Sep 26 12:13:59.479012 (XEN) [<ffff82c48026f576>]
alloc_ivrs_mappings+0x14/0x18b
Sep 26 12:13:59.483042 (XEN) [<ffff82c480270508>]
amd_iommu_detect_one_acpi+0x108/0x300
Sep 26 12:13:59.491039 (XEN) [<ffff82c480271f5f>]
detect_iommu_acpi+0xa3/0xd4
Sep 26 12:13:59.498633 (XEN) [<ffff82c48027238b>]
acpi_table_parse+0x6e/0x7c
Sep 26 12:13:59.502631 (XEN) [<ffff82c4802707df>]
amd_iommu_detect_acpi+0x17/0x19
Sep 26 12:13:59.511033 (XEN) [<ffff82c48026ff9b>]
amd_iov_detect+0x1a/0xcf
Sep 26 12:13:59.519034 (XEN) [<ffff82c48026cfc7>]
iommu_setup+0x67/0x151
Sep 26 12:13:59.522631 (XEN) [<ffff82c48027e179>]
__start_xen+0x258a/0x2931
Sep 26 12:13:59.530665 (XEN)
Sep 26 12:13:59.530702 (XEN)
Sep 26 12:13:59.534602 (XEN) ****************************************
Sep 26 12:13:59.539024 (XEN) Panic on CPU 0:
Sep 26 12:13:59.542612 (XEN) Xen BUG at iommu_init.c:777
Sep 26 12:13:59.546620 (XEN) ****************************************
Sep 26 12:13:59.555029 (XEN)
Sep 26 12:13:59.555065 (XEN) Reboot in five seconds...
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jan Beulich
2011-Sep-27 12:58 UTC
[Xen-devel] Re: [xen-unstable test] 9085: regressions - FAIL
>>> On 27.09.11 at 14:37, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > xen.org writes ("[xen-unstable test] 9085: regressions - FAIL"): >> test-amd64-i386-xl 5 xen-boot fail pass in 9083 > > Boot failure on machines with AMD IOMMU, I think.I did send a patch for this on Friday (http://lists.xensource.com/archives/html/xen-devel/2011-09/msg01281.html), but it didn''t get applied so far. Jan> Ian. > > Sep 26 12:13:59.207009 (XEN) PCI: Using MCFG for segment 0000 bus 00-ff > Sep 26 12:13:59.214606 (XEN) Xen BUG at iommu_init.c:777 > Sep 26 12:13:59.218999 (XEN) ----[ Xen-4.2-unstable x86_64 debug=y Not tainted > ]---- > Sep 26 12:13:59.226620 (XEN) CPU: 0 > Sep 26 12:13:59.226659 (XEN) RIP: e008:[<ffff82c48026f576>] > alloc_ivrs_mappings+0x14/0x18b > Sep 26 12:13:59.235021 (XEN) RFLAGS: 0000000000010246 CONTEXT: hypervisor > Sep 26 12:13:59.243013 (XEN) rax: 0000000000000000 rbx: ffff8302155faee0 > rcx: 0000000000000000 > Sep 26 12:13:59.250624 (XEN) rdx: 0000000000000000 rsi: 0000000000000010 > rdi: 0000000000000000 > Sep 26 12:13:59.259027 (XEN) rbp: ffff82c4802a7d58 rsp: ffff82c4802a7d48 > r8: ffff83021b202004 > Sep 26 12:13:59.266626 (XEN) r9: 0000000000000010 r10: 0000000000000004 > r11: 0000000000000001 > Sep 26 12:13:59.274671 (XEN) r12: 0000000000000000 r13: ffff82c3ffd7a620 > r14: ffff82c3ffd7a620 > Sep 26 12:13:59.282628 (XEN) r15: ffff83000007bfb0 cr0: 000000008005003b > cr4: 00000000000006f0 > Sep 26 12:13:59.290627 (XEN) cr3: 00000000dfcac000 cr2: 0000000000000000 > Sep 26 12:13:59.295026 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: > 0000 cs: e008 > Sep 26 12:13:59.303027 (XEN) Xen stack trace from rsp=ffff82c4802a7d48: > Sep 26 12:13:59.310613 (XEN) ffff8302155faee0 ffff82c3ffd7a650 > ffff82c4802a7da8 ffff82c480270508 > Sep 26 12:13:59.318631 (XEN) ffff82c4802a7df0 ffff83000007bf30 > ffff82c4802a7d98 0000000000000030 > Sep 26 12:13:59.326629 (XEN) ffff82c3ffd7a650 ffff82c3ffd7a620 > ffff82c3ffd7a620 ffff83000007bfb0 > Sep 26 12:13:59.334630 (XEN) ffff82c4802a7dd8 ffff82c480271f5f > ffff82c480271ebc ffff82c48028adbd > Sep 26 12:13:59.342631 (XEN) ffff83000007bf30 ffff83000007bf30 > ffff82c4802a7e08 ffff82c48027238b > Sep 26 12:13:59.350631 (XEN) ffff8302155faea0 ffff82c3ffd7a620 > 00000000ffffffed 0000000000000000 > Sep 26 12:13:59.359035 (XEN) ffff82c4802a7e18 ffff82c4802707df > ffff82c4802a7e28 ffff82c48026ff9b > Sep 26 12:13:59.366656 (XEN) ffff82c4802a7e48 ffff82c48026cfc7 > ffff82c4802a7f18 ffff83000007bfb0 > Sep 26 12:13:59.374634 (XEN) ffff82c4802a7f08 ffff82c48027e179 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.382632 (XEN) ffff83000007bdc0 000000000084a000 > 00000000dfa00000 0000000000000000 > Sep 26 12:13:59.390632 (XEN) 00000000002f6280 ffff82c4802d9574 > ffff83000007bf30 00000000ffffffff > Sep 26 12:13:59.399033 (XEN) ffff82c400000004 ffff830000000003 > 0000000800000000 000000010000006e > Sep 26 12:13:59.406634 (XEN) 0000000000000003 00000000000002f8 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.414634 (XEN) 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.422635 (XEN) 000000000007fe0c ffff82c4801000b5 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.430737 (XEN) 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.442655 (XEN) 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.451039 (XEN) 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.458638 (XEN) 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.466638 (XEN) 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 > Sep 26 12:13:59.474638 (XEN) Xen call trace: > Sep 26 12:13:59.479012 (XEN) [<ffff82c48026f576>] > alloc_ivrs_mappings+0x14/0x18b > Sep 26 12:13:59.483042 (XEN) [<ffff82c480270508>] > amd_iommu_detect_one_acpi+0x108/0x300 > Sep 26 12:13:59.491039 (XEN) [<ffff82c480271f5f>] > detect_iommu_acpi+0xa3/0xd4 > Sep 26 12:13:59.498633 (XEN) [<ffff82c48027238b>] > acpi_table_parse+0x6e/0x7c > Sep 26 12:13:59.502631 (XEN) [<ffff82c4802707df>] > amd_iommu_detect_acpi+0x17/0x19 > Sep 26 12:13:59.511033 (XEN) [<ffff82c48026ff9b>] amd_iov_detect+0x1a/0xcf > Sep 26 12:13:59.519034 (XEN) [<ffff82c48026cfc7>] iommu_setup+0x67/0x151 > Sep 26 12:13:59.522631 (XEN) [<ffff82c48027e179>] __start_xen+0x258a/0x2931 > Sep 26 12:13:59.530665 (XEN) > Sep 26 12:13:59.530702 (XEN) > Sep 26 12:13:59.534602 (XEN) **************************************** > Sep 26 12:13:59.539024 (XEN) Panic on CPU 0: > Sep 26 12:13:59.542612 (XEN) Xen BUG at iommu_init.c:777 > Sep 26 12:13:59.546620 (XEN) **************************************** > Sep 26 12:13:59.555029 (XEN) > Sep 26 12:13:59.555065 (XEN) Reboot in five seconds... > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2011-Sep-27 13:15 UTC
[Xen-devel] Re: [xen-unstable test] 9085: regressions - FAIL
Jan Beulich writes ("[Xen-devel] Re: [xen-unstable test] 9085: regressions
- FAIL"):> >>> On 27.09.11 at 14:37, Ian Jackson
<Ian.Jackson@eu.citrix.com> wrote:
> > xen.org writes ("[xen-unstable test] 9085: regressions -
FAIL"):
> >> test-amd64-i386-xl 5 xen-boot fail
pass in 9083
> >
> > Boot failure on machines with AMD IOMMU, I think.
>
> I did send a patch for this on Friday
(http://lists.xensource.com/archives/html/xen-devel/2011-09/msg01281.html), but
it didn''t get applied so far.
Keir ? I''m not qualified to review this patch but it''s
currently
pretty badly broken...
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel