flight 14494 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/14494/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pv 5 xen-boot fail REGR. vs. 14482 test-amd64-i386-qemut-rhel6hvm-amd 5 xen-boot fail REGR. vs. 14482 test-amd64-i386-xl-multivcpu 5 xen-boot fail REGR. vs. 14482 test-amd64-i386-xl 5 xen-boot fail REGR. vs. 14482 test-amd64-i386-qemuu-rhel6hvm-amd 5 xen-boot fail REGR. vs. 14482 test-amd64-amd64-xl-qemuu-win7-amd64 5 xen-boot fail REGR. vs. 14482 test-amd64-i386-pair 8 xen-boot/dst_host fail REGR. vs. 14482 test-amd64-i386-pair 7 xen-boot/src_host fail REGR. vs. 14482 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 14482 test-amd64-i386-xl-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 14482 test-amd64-amd64-pair 8 xen-boot/dst_host fail REGR. vs. 14482 test-amd64-amd64-pair 7 xen-boot/src_host fail REGR. vs. 14482 test-amd64-i386-xend-qemut-winxpsp3 5 xen-boot fail REGR. vs. 14482 test-amd64-i386-qemut-win 5 xen-boot fail REGR. vs. 14482 test-amd64-amd64-xl-win 5 xen-boot fail REGR. vs. 14482 test-amd64-amd64-xl-win7-amd64 5 xen-boot fail REGR. vs. 14482 test-amd64-amd64-qemut-win 5 xen-boot fail REGR. vs. 14482 test-amd64-amd64-xl-qemut-win 5 xen-boot fail REGR. vs. 14482 test-amd64-amd64-xl-qemut-winxpsp3 5 xen-boot fail REGR. vs. 14482 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 5 xen-boot fail REGR. vs. 14482 test-amd64-amd64-xl-sedf 5 xen-boot fail like 14482 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass test-amd64-i386-qemut-win-vcpus1 16 leak-check/check fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass version targeted for testing: xen 9d88ac6046d8 baseline version: xen 1c69c938f641 ------------------------------------------------------------ People who touched revisions under test: George Dunlap <george.dunlap@eu.citrix.com> Ian Campbell <ian.campbell@citrix.com> Jan Beulich <jbeulich@suse.com> Keir Fraser <keir@xen.org> Kouya Shimura <kouya@jp.fujitsu.com> Roger Pau Monn? <roger.pau@citrix.com> Stefano Stabellini <stefano.stabellini@eu.citrix.com> Tim Deegan <tim@xen.org> ------------------------------------------------------------ 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 fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail 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 fail test-amd64-amd64-pair fail test-amd64-i386-pair fail test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv fail test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-qemut-win-vcpus1 fail test-amd64-i386-xl-qemut-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-qemut-win fail test-amd64-i386-qemut-win fail test-amd64-amd64-xl-qemut-win fail test-amd64-amd64-xl-win 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. ------------------------------------------------------------ changeset: 26205:9d88ac6046d8 tag: tip user: Roger Pau Monne <roger.pau@citrix.com> date: Thu Nov 29 11:28:18 2012 +0000 docs: fix persistent grants doc typo Signed-off-by: Roger Pau Monn? <roger.pau@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> [ ijc -- fix additional typo s/this grants/these grants/g ] Committed-by: Ian Campbell <ian.campbell@citrix.com> changeset: 26204:48e211812551 user: Stefano Stabellini <stefano.stabellini@eu.citrix.com> date: Thu Nov 29 11:28:17 2012 +0000 xen/arm: build as zImage The zImage format is extremely simple: it only consists of a magic number and 2 addresses in a specific position (see http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html#d0e309). Some bootloaders expect a zImage; considering that it doesn''t cost us much to build Xen compatible with the format, make it so. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Tim Deegan <tim@xen.org> Acked-by: Ian Campbell <ian.campbell@citrix.com> [ ijc -- switch from 7*nop + nop to just 8*nop ] Committed-by: Ian Campbell <ian.campbell@citrix.com> changeset: 26203:b5cb6cccc32c user: Tim Deegan <tim@xen.org> date: Thu Nov 29 11:01:00 2012 +0000 x86/hap: Fix memory leak of domain->arch.hvm_domain.dirty_vram Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> Signed-off-by: Tim Deegan <tim@xen.org> Committed-by: Tim Deegan <tim@xen.org> changeset: 26202:9c6c13bf3803 user: Tim Deegan <tim@xen.org> date: Thu Nov 29 10:49:53 2012 +0000 x86/mm: Comment the definitions of _mfn(), _gfn() &c. It''s not very easy to find them if you don''t know to look for the TYPE_SAFE() macro. Signed-off-by: Tim Deegan <tim@xen.org> Committed-by: Tim Deegan <tim@xen.org> changeset: 26201:5d7e3c2742e8 user: Jan Beulich <jbeulich@suse.com> date: Thu Nov 29 09:14:55 2012 +0100 VT-d: make scope parsing code type safe Rather than requiring the scopes to be the first members of their respective structures (so that casts can be used to switch between the different views), properly use types and container_of(). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by Xiantao Zhang <xiantao.zhang@intel.com> changeset: 26200:836697b19746 user: Jan Beulich <jbeulich@suse.com> date: Wed Nov 28 17:00:56 2012 +0100 IOMMU: imply "verbose" from "debug" I think that generally enabling debugging code without also enabling verbose output is rather pointless; if someone really wants this, they can always pass e.g. "iommu=debug,no-verbose". Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> changeset: 26199:1fce7522daa6 user: Jan Beulich <jbeulich@suse.com> date: Wed Nov 28 10:08:24 2012 +0100 VT-d: adjust IOMMU interrupt affinities when all CPUs are online Since these interrupts get setup before APs get brought online, their affinities naturally could only ever point to CPU 0 alone so far. Adjust this to include potentially multiple CPUs in the target mask (when running in one of the cluster modes), and take into account NUMA information (to handle the interrupts on a CPU on the node where the respective IOMMU is). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> changeset: 26198:ba90ecb0231f user: Jan Beulich <jbeulich@suse.com> date: Wed Nov 28 10:07:11 2012 +0100 AMD IOMMU: include IOMMU interrupt information in ''M'' debug key output Note that this also adds a few pieces missing from c/s 25903:5e4a00b4114c (relevant only when the PCI MSI mask bit is supported by an IOMMU, which apparently isn''t the case for existing implementations). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> changeset: 26197:0bc3a489018f user: Jan Beulich <jbeulich@suse.com> date: Wed Nov 28 10:05:52 2012 +0100 VT-d: include IOMMU interrupt information in ''M'' debug key output Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> changeset: 26196:5faf5b8b702e user: Jan Beulich <jbeulich@suse.com> date: Wed Nov 28 10:03:51 2012 +0100 ACPI: fix return value of XEN_PM_PDC platform op Should return -EFAULT when copying to guest memory fails. Once touching this code, also switch to using the more relaxed copy function (copying from the same guest memory already validated the virtual address range). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> changeset: 26195:7670eabcbafc user: Jan Beulich <jbeulich@suse.com> date: Wed Nov 28 10:02:26 2012 +0100 x86: fix hypercall continuation cancellation in XENMAPSPACE_gmfn_range compat wrapper When no continuation was established, there must also not be an attempt to cancel it - hypercall_cancel_continuation(), in the non-HVM, non- multicall case, adjusts the guest mode return address in a way assuming that an earlier call hypercall_create_continuation() took place. Once touching this code, also restructure it slightly to improve readability and switch to using the more relaxed copy function (copying from the same guest memory already validated the virtual address range). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> changeset: 26194:0aa1c5136a54 user: Jan Beulich <jbeulich@suse.com> date: Wed Nov 28 10:01:33 2012 +0100 README: adjust gcc version requirement Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> changeset: 26193:1c69c938f641 user: George Dunlap <george.dunlap@eu.citrix.com> date: Tue Nov 27 14:13:41 2012 +0000 libxl: Fix bug in libxl_cdrom_insert, make more robust against bad xenstore data libxl_cdrom_insert was failing to initialize the backend type, resulting in the wrong default backend. The result was not only that the CD was not inserted properly, but also that some improper xenstore entries were created, causing further block commands to fail. This patch fixes the bug by setting the disk backend type based on the type of the existing device. It also makes the system more robust by checking to see that it has got a valid path before proceeding to write a partial xenstore entry. Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Committed-by: Ian Campbell <ian.campbell@citrix.com> (qemu changes not included)
On Thu, 2012-11-29 at 21:13 +0000, xen.org wrote:> flight 14494 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/14494/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-amd64-pv 5 xen-boot fail REGR. vs. 14482Jan, I assume this relates to your "AMD IOMMU: add locking missing from c/s 26198:ba90ecb0231f" from this morning? Nov 29 17:53:03.732540 (XEN) Assertion ''spin_is_locked(&desc->lock)'' failed at msi.c:276 Nov 29 17:53:03.740545 (XEN) ----[ Xen-4.3-unstable x86_64 debug=y Not tainted ]---- Nov 29 17:53:03.748543 (XEN) CPU: 0 Nov 29 17:53:03.748570 (XEN) RIP: e008:[<ffff82c48016607d>] set_msi_affinity+0x4a/0x1ba Nov 29 17:53:03.756539 (XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor Nov 29 17:53:03.764538 (XEN) rax: 0000000000000000 rbx: ffff830116381880 rcx: 0000000000000000 Nov 29 17:53:03.772548 (XEN) rdx: 0000000000000082 rsi: ffff82c480260280 rdi: ffff8301163818a8 Nov 29 17:53:03.780548 (XEN) rbp: ffff82c4802bfd78 rsp: ffff82c4802bfd28 r8: 0000000000000020 Nov 29 17:53:03.788548 (XEN) r9: 0000000000000081 r10: 0000000000000001 r11: ffff82c4802cbe40 Nov 29 17:53:03.796542 (XEN) r12: ffff8301163f0370 r13: 0000000000000001 r14: 0000000000000296 Nov 29 17:53:03.804547 (XEN) r15: ffff82c4802e7f88 cr0: 000000008005003b cr4: 00000000000006f0 Nov 29 17:53:03.812547 (XEN) cr3: 00000000dfc6f000 cr2: 0000000000000000 Nov 29 17:53:03.820532 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 Nov 29 17:53:03.828539 (XEN) Xen stack trace from rsp=ffff82c4802bfd28: Nov 29 17:53:03.832541 (XEN) ffff82c4802bfd38 0000000000000282 ffff82c4802bfd68 ffff82c480291d5a Nov 29 17:53:03.840548 (XEN) 0000000000000018 ffff8301163f0350 ffff8301163f0360 ffff82c4802e7f80 Nov 29 17:53:03.848549 (XEN) 0000000000000296 ffff82c4802e7f88 ffff82c4802bfdb8 ffff82c48014cea4 Nov 29 17:53:03.856541 (XEN) ffff82c3fffff000 ffff8301163f0350 ffff82c3fffff000 ffff82c4802e7f80 Nov 29 17:53:03.864553 (XEN) ffff82c4802e7f90 ffff82c4802e7f88 ffff82c4802bfe18 ffff82c480288e98 Nov 29 17:53:03.872548 (XEN) ffff8301163fbfe0 0000000000000018 ffff830116381880 000000188028d379 Nov 29 17:53:03.884540 (XEN) 00000000e0000000 00000000ffffffed 0000000000000000 ffff8301163fbfe0 Nov 29 17:53:03.892538 (XEN) 0000000000000002 0000000000000002 ffff82c4802bfe28 ffff82c480289256 Nov 29 17:53:03.900541 (XEN) ffff82c4802bfe48 ffff82c480285fce ffff82c4802b8000 ffff830000089fb0 Nov 29 17:53:03.908541 (XEN) ffff82c4802bff08 ffff82c4802975f5 0000000000000000 0000000000000000 Nov 29 17:53:03.916541 (XEN) ffff830000089dd0 0000000000f10000 00000000dfa00000 0000000000000000 Nov 29 17:53:03.924538 (XEN) 0000000000301780 ffff82c4ffffffff ffff830000000003 ffff830000089f30 Nov 29 17:53:03.932544 (XEN) ffff830000089fb0 ffff82c4ffffffff 0000000800000000 000000010000006e Nov 29 17:53:03.940546 (XEN) 0000000000000003 00000000000002f8 0000000000000000 0000000000000000 Nov 29 17:53:03.948545 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Nov 29 17:53:03.956546 (XEN) 000000000007fe0c ffff82c4801000b5 0000000000000000 0000000000000000 Nov 29 17:53:03.964546 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Nov 29 17:53:03.972545 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Nov 29 17:53:03.980545 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Nov 29 17:53:03.988548 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Nov 29 17:53:03.996551 (XEN) Xen call trace: Nov 29 17:53:04.000522 (XEN) [<ffff82c48016607d>] set_msi_affinity+0x4a/0x1ba Nov 29 17:53:04.008538 (XEN) [<ffff82c48014cea4>] enable_iommu+0x54d/0x68f Nov 29 17:53:04.012543 (XEN) [<ffff82c480288e98>] amd_iommu_init+0x4d0/0x65a Nov 29 17:53:04.020542 (XEN) [<ffff82c480289256>] amd_iov_detect+0x6c/0xf6 Nov 29 17:53:04.028535 (XEN) [<ffff82c480285fce>] iommu_setup+0x67/0x143 Nov 29 17:53:04.032533 (XEN) [<ffff82c4802975f5>] __start_xen+0x269d/0x2acd Nov 29 17:53:04.040537 (XEN) Nov 29 17:53:04.040559 (XEN) Nov 29 17:53:04.040581 (XEN) **************************************** Nov 29 17:53:04.048557 (XEN) Panic on CPU 0: Nov 29 17:53:04.052523 (XEN) Assertion ''spin_is_locked(&desc->lock)'' failed at msi.c:276 Nov 29 17:53:04.060538 (XEN) ****************************************
>>> On 30.11.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Thu, 2012-11-29 at 21:13 +0000, xen.org wrote: >> flight 14494 xen-unstable real [real] >> http://www.chiark.greenend.org.uk/~xensrcts/logs/14494/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> test-amd64-amd64-pv 5 xen-boot fail REGR. vs. > 14482 > > Jan, I assume this relates to your "AMD IOMMU: add locking missing from > c/s 26198:ba90ecb0231f" from this morning?Yes, that patch was prompted by these failures. I''ll be in the office today only until about 1pm, so I''ll wait for a little more to see if I can get e.g. Keir''s ack on it, but will try to remember to commit it even without before leaving. Jan> Nov 29 17:53:03.732540 (XEN) Assertion ''spin_is_locked(&desc->lock)'' > failed at msi.c:276 > Nov 29 17:53:03.740545 (XEN) ----[ Xen-4.3-unstable x86_64 debug=y Not > tainted ]---- > Nov 29 17:53:03.748543 (XEN) CPU: 0 > Nov 29 17:53:03.748570 (XEN) RIP: e008:[<ffff82c48016607d>] > set_msi_affinity+0x4a/0x1ba > Nov 29 17:53:03.756539 (XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor > Nov 29 17:53:03.764538 (XEN) rax: 0000000000000000 rbx: ffff830116381880 > rcx: 0000000000000000 > Nov 29 17:53:03.772548 (XEN) rdx: 0000000000000082 rsi: ffff82c480260280 > rdi: ffff8301163818a8 > Nov 29 17:53:03.780548 (XEN) rbp: ffff82c4802bfd78 rsp: ffff82c4802bfd28 > r8: 0000000000000020 > Nov 29 17:53:03.788548 (XEN) r9: 0000000000000081 r10: 0000000000000001 > r11: ffff82c4802cbe40 > Nov 29 17:53:03.796542 (XEN) r12: ffff8301163f0370 r13: 0000000000000001 > r14: 0000000000000296 > Nov 29 17:53:03.804547 (XEN) r15: ffff82c4802e7f88 cr0: 000000008005003b > cr4: 00000000000006f0 > Nov 29 17:53:03.812547 (XEN) cr3: 00000000dfc6f000 cr2: 0000000000000000 > Nov 29 17:53:03.820532 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: > 0000 cs: e008 > Nov 29 17:53:03.828539 (XEN) Xen stack trace from rsp=ffff82c4802bfd28: > Nov 29 17:53:03.832541 (XEN) ffff82c4802bfd38 0000000000000282 > ffff82c4802bfd68 ffff82c480291d5a > Nov 29 17:53:03.840548 (XEN) 0000000000000018 ffff8301163f0350 > ffff8301163f0360 ffff82c4802e7f80 > Nov 29 17:53:03.848549 (XEN) 0000000000000296 ffff82c4802e7f88 > ffff82c4802bfdb8 ffff82c48014cea4 > Nov 29 17:53:03.856541 (XEN) ffff82c3fffff000 ffff8301163f0350 > ffff82c3fffff000 ffff82c4802e7f80 > Nov 29 17:53:03.864553 (XEN) ffff82c4802e7f90 ffff82c4802e7f88 > ffff82c4802bfe18 ffff82c480288e98 > Nov 29 17:53:03.872548 (XEN) ffff8301163fbfe0 0000000000000018 > ffff830116381880 000000188028d379 > Nov 29 17:53:03.884540 (XEN) 00000000e0000000 00000000ffffffed > 0000000000000000 ffff8301163fbfe0 > Nov 29 17:53:03.892538 (XEN) 0000000000000002 0000000000000002 > ffff82c4802bfe28 ffff82c480289256 > Nov 29 17:53:03.900541 (XEN) ffff82c4802bfe48 ffff82c480285fce > ffff82c4802b8000 ffff830000089fb0 > Nov 29 17:53:03.908541 (XEN) ffff82c4802bff08 ffff82c4802975f5 > 0000000000000000 0000000000000000 > Nov 29 17:53:03.916541 (XEN) ffff830000089dd0 0000000000f10000 > 00000000dfa00000 0000000000000000 > Nov 29 17:53:03.924538 (XEN) 0000000000301780 ffff82c4ffffffff > ffff830000000003 ffff830000089f30 > Nov 29 17:53:03.932544 (XEN) ffff830000089fb0 ffff82c4ffffffff > 0000000800000000 000000010000006e > Nov 29 17:53:03.940546 (XEN) 0000000000000003 00000000000002f8 > 0000000000000000 0000000000000000 > Nov 29 17:53:03.948545 (XEN) 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 > Nov 29 17:53:03.956546 (XEN) 000000000007fe0c ffff82c4801000b5 > 0000000000000000 0000000000000000 > Nov 29 17:53:03.964546 (XEN) 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 > Nov 29 17:53:03.972545 (XEN) 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 > Nov 29 17:53:03.980545 (XEN) 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 > Nov 29 17:53:03.988548 (XEN) 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 > Nov 29 17:53:03.996551 (XEN) Xen call trace: > Nov 29 17:53:04.000522 (XEN) [<ffff82c48016607d>] > set_msi_affinity+0x4a/0x1ba > Nov 29 17:53:04.008538 (XEN) [<ffff82c48014cea4>] enable_iommu+0x54d/0x68f > Nov 29 17:53:04.012543 (XEN) [<ffff82c480288e98>] > amd_iommu_init+0x4d0/0x65a > Nov 29 17:53:04.020542 (XEN) [<ffff82c480289256>] amd_iov_detect+0x6c/0xf6 > Nov 29 17:53:04.028535 (XEN) [<ffff82c480285fce>] iommu_setup+0x67/0x143 > Nov 29 17:53:04.032533 (XEN) [<ffff82c4802975f5>] __start_xen+0x269d/0x2acd > Nov 29 17:53:04.040537 (XEN) > Nov 29 17:53:04.040559 (XEN) > Nov 29 17:53:04.040581 (XEN) **************************************** > Nov 29 17:53:04.048557 (XEN) Panic on CPU 0: > Nov 29 17:53:04.052523 (XEN) Assertion ''spin_is_locked(&desc->lock)'' failed at > msi.c:276 > Nov 29 17:53:04.060538 (XEN) ****************************************
On 30/11/2012 09:48, "Jan Beulich" <JBeulich@suse.com> wrote:>>>> On 30.11.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> On Thu, 2012-11-29 at 21:13 +0000, xen.org wrote: >>> flight 14494 xen-unstable real [real] >>> http://www.chiark.greenend.org.uk/~xensrcts/logs/14494/ >>> >>> Regressions :-( >>> >>> Tests which did not succeed and are blocking, >>> including tests which could not be run: >>> test-amd64-amd64-pv 5 xen-boot fail REGR. vs. >> 14482 >> >> Jan, I assume this relates to your "AMD IOMMU: add locking missing from >> c/s 26198:ba90ecb0231f" from this morning? > > Yes, that patch was prompted by these failures. I''ll be in the > office today only until about 1pm, so I''ll wait for a little more to > see if I can get e.g. Keir''s ack on it, but will try to remember to > commit it even without before leaving.I have just sent an Ack. K.> Jan > >> Nov 29 17:53:03.732540 (XEN) Assertion ''spin_is_locked(&desc->lock)'' >> failed at msi.c:276 >> Nov 29 17:53:03.740545 (XEN) ----[ Xen-4.3-unstable x86_64 debug=y Not >> tainted ]---- >> Nov 29 17:53:03.748543 (XEN) CPU: 0 >> Nov 29 17:53:03.748570 (XEN) RIP: e008:[<ffff82c48016607d>] >> set_msi_affinity+0x4a/0x1ba >> Nov 29 17:53:03.756539 (XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor >> Nov 29 17:53:03.764538 (XEN) rax: 0000000000000000 rbx: ffff830116381880 >> rcx: 0000000000000000 >> Nov 29 17:53:03.772548 (XEN) rdx: 0000000000000082 rsi: ffff82c480260280 >> rdi: ffff8301163818a8 >> Nov 29 17:53:03.780548 (XEN) rbp: ffff82c4802bfd78 rsp: ffff82c4802bfd28 >> r8: 0000000000000020 >> Nov 29 17:53:03.788548 (XEN) r9: 0000000000000081 r10: 0000000000000001 >> r11: ffff82c4802cbe40 >> Nov 29 17:53:03.796542 (XEN) r12: ffff8301163f0370 r13: 0000000000000001 >> r14: 0000000000000296 >> Nov 29 17:53:03.804547 (XEN) r15: ffff82c4802e7f88 cr0: 000000008005003b >> cr4: 00000000000006f0 >> Nov 29 17:53:03.812547 (XEN) cr3: 00000000dfc6f000 cr2: 0000000000000000 >> Nov 29 17:53:03.820532 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: >> 0000 cs: e008 >> Nov 29 17:53:03.828539 (XEN) Xen stack trace from rsp=ffff82c4802bfd28: >> Nov 29 17:53:03.832541 (XEN) ffff82c4802bfd38 0000000000000282 >> ffff82c4802bfd68 ffff82c480291d5a >> Nov 29 17:53:03.840548 (XEN) 0000000000000018 ffff8301163f0350 >> ffff8301163f0360 ffff82c4802e7f80 >> Nov 29 17:53:03.848549 (XEN) 0000000000000296 ffff82c4802e7f88 >> ffff82c4802bfdb8 ffff82c48014cea4 >> Nov 29 17:53:03.856541 (XEN) ffff82c3fffff000 ffff8301163f0350 >> ffff82c3fffff000 ffff82c4802e7f80 >> Nov 29 17:53:03.864553 (XEN) ffff82c4802e7f90 ffff82c4802e7f88 >> ffff82c4802bfe18 ffff82c480288e98 >> Nov 29 17:53:03.872548 (XEN) ffff8301163fbfe0 0000000000000018 >> ffff830116381880 000000188028d379 >> Nov 29 17:53:03.884540 (XEN) 00000000e0000000 00000000ffffffed >> 0000000000000000 ffff8301163fbfe0 >> Nov 29 17:53:03.892538 (XEN) 0000000000000002 0000000000000002 >> ffff82c4802bfe28 ffff82c480289256 >> Nov 29 17:53:03.900541 (XEN) ffff82c4802bfe48 ffff82c480285fce >> ffff82c4802b8000 ffff830000089fb0 >> Nov 29 17:53:03.908541 (XEN) ffff82c4802bff08 ffff82c4802975f5 >> 0000000000000000 0000000000000000 >> Nov 29 17:53:03.916541 (XEN) ffff830000089dd0 0000000000f10000 >> 00000000dfa00000 0000000000000000 >> Nov 29 17:53:03.924538 (XEN) 0000000000301780 ffff82c4ffffffff >> ffff830000000003 ffff830000089f30 >> Nov 29 17:53:03.932544 (XEN) ffff830000089fb0 ffff82c4ffffffff >> 0000000800000000 000000010000006e >> Nov 29 17:53:03.940546 (XEN) 0000000000000003 00000000000002f8 >> 0000000000000000 0000000000000000 >> Nov 29 17:53:03.948545 (XEN) 0000000000000000 0000000000000000 >> 0000000000000000 0000000000000000 >> Nov 29 17:53:03.956546 (XEN) 000000000007fe0c ffff82c4801000b5 >> 0000000000000000 0000000000000000 >> Nov 29 17:53:03.964546 (XEN) 0000000000000000 0000000000000000 >> 0000000000000000 0000000000000000 >> Nov 29 17:53:03.972545 (XEN) 0000000000000000 0000000000000000 >> 0000000000000000 0000000000000000 >> Nov 29 17:53:03.980545 (XEN) 0000000000000000 0000000000000000 >> 0000000000000000 0000000000000000 >> Nov 29 17:53:03.988548 (XEN) 0000000000000000 0000000000000000 >> 0000000000000000 0000000000000000 >> Nov 29 17:53:03.996551 (XEN) Xen call trace: >> Nov 29 17:53:04.000522 (XEN) [<ffff82c48016607d>] >> set_msi_affinity+0x4a/0x1ba >> Nov 29 17:53:04.008538 (XEN) [<ffff82c48014cea4>] enable_iommu+0x54d/0x68f >> Nov 29 17:53:04.012543 (XEN) [<ffff82c480288e98>] >> amd_iommu_init+0x4d0/0x65a >> Nov 29 17:53:04.020542 (XEN) [<ffff82c480289256>] amd_iov_detect+0x6c/0xf6 >> Nov 29 17:53:04.028535 (XEN) [<ffff82c480285fce>] iommu_setup+0x67/0x143 >> Nov 29 17:53:04.032533 (XEN) [<ffff82c4802975f5>] >> __start_xen+0x269d/0x2acd >> Nov 29 17:53:04.040537 (XEN) >> Nov 29 17:53:04.040559 (XEN) >> Nov 29 17:53:04.040581 (XEN) **************************************** >> Nov 29 17:53:04.048557 (XEN) Panic on CPU 0: >> Nov 29 17:53:04.052523 (XEN) Assertion ''spin_is_locked(&desc->lock)'' failed >> at >> msi.c:276 >> Nov 29 17:53:04.060538 (XEN) **************************************** > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel