iommu is disabled since cset 19175:ab514cfbcdc5 with the following message: (XEN) [VT-D]iommu.c:890:d32767 IOMMU: can''t request irq (XEN) [VT-D]iommu.c:1686:d32767 IOMMU: interrupt setup failed (XEN) I/O virtualisation disabled This patch fixes it. - rename request_irq to request_vector, no conversion by irq_to_vector(irq) - set vector_to_iommu[vector] before calling request_vector since null pointer exceptions occurs - some cleanups Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Espen and Isaku have a patch now which should hopefully also fix this issue. I''ll be checking theirs in shortly. Thanks, Keir On 12/02/2009 02:59, "Kouya Shimura" <kouya@jp.fujitsu.com> wrote:> iommu is disabled since cset 19175:ab514cfbcdc5 with the following message: > > (XEN) [VT-D]iommu.c:890:d32767 IOMMU: can''t request irq > (XEN) [VT-D]iommu.c:1686:d32767 IOMMU: interrupt setup failed > (XEN) I/O virtualisation disabled > > This patch fixes it. > - rename request_irq to request_vector, no conversion by irq_to_vector(irq) > - set vector_to_iommu[vector] before calling request_vector > since null pointer exceptions occurs > - some cleanups > > Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Interrupt handling cleanup in changeset 19195 is causing following failure on my system: (XEN) ----[ Xen-3.4-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e008:[<ffff828c8011b591>] check_lock+0x19/0x4e (XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor (XEN) rax: 0000000000000001 rbx: 0000000000000040 rcx: 0000000000000001 (XEN) rdx: 0000000000000082 rsi: 0000000000000001 rdi: 0000000000000044 (XEN) rbp: ffff828c80277c58 rsp: ffff828c80277c58 r8: 0000000000000005 (XEN) r9: 0000000000000001 r10: 0000000000000001 r11: 0000000000000000 (XEN) r12: 0000000000000082 r13: 0000000000000282 r14: 0000000000000090 (XEN) r15: ffff83007f2c4160 cr0: 000000008005003b cr4: 00000000000026f0 (XEN) cr3: 000000007f47c000 cr2: 0000000000000044 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Xen stack trace from rsp=ffff828c80277c58: (XEN) ffff828c80277c78 ffff828c8011b70c 0000000000000000 0000000000000040 (XEN) ffff828c80277c98 ffff828c8012df24 ffff828c802a1c00 ffff828c802a1c24 (XEN) ffff828c80277ca8 ffff828c8012df83 ffff828c80277ce8 ffff828c80147cc0 (XEN) ffff828c80277ce8 00000000fffffff4 0000000000000090 ffff828c8012e639 (XEN) ffff828c801e2191 ffff83007f4d9df0 ffff828c80277d28 ffff828c801481fa (XEN) ffff83007f2c4160 0000000000000090 ffff83007f4d9df0 0000000000004800 (XEN) ffff83007f4d9df0 ffff828c8029d400 ffff828c80277d68 ffff828c8012e2f0 (XEN) ffff828c80277d48 0000000000000000 ffff83007f4d9df0 0000000000000282 (XEN) ffff83007f6df130 0000000000100000 ffff828c80277d98 ffff828c8012e4a2 (XEN) 0000000000000000 ffff83007f4d9df0 ffff828c8020b8b0 0000000000000020 (XEN) ffff828c80277de8 ffff828c8012fb38 ffff828c80277dd8 ffff828c8012a183 (XEN) 0000000000000004 00010001802093c0 0001000100010001 00000000ffffffed (XEN) ffff828c8022ec08 0000000000000017 ffff828c80277e08 ffff828c8012be18 (XEN) ffff828c80277e08 ffff828c8022eaf8 ffff828c80277f18 ffff828c80222ca8 (XEN) 0000000000000000 0000000000000000 0000000000000000 ffff828c8020e675 (XEN) ffffffffc0270000 ffff83007f47cff8 ffff83007f47dff8 000000000020e610 (XEN) 000000000008bf60 0000000000000000 0000000000000000 0000000000000000 (XEN) ffff83000008bfc0 ffff83000008bf60 0000000000b0c800 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000800000000 000000010000006e (XEN) Xen call trace: (XEN) [<ffff828c8011b591>] check_lock+0x19/0x4e (XEN) [<ffff828c8011b70c>] _spin_lock_irqsave+0x21/0x3f (XEN) [<ffff828c8012df24>] dma_msi_unmask+0x2a/0x4b (XEN) [<ffff828c8012df83>] dma_msi_startup+0x9/0x10 (XEN) [<ffff828c80147cc0>] setup_irq_vector+0x73/0x99 (XEN) [<ffff828c801481fa>] request_irq_vector+0x6c/0x9a (XEN) [<ffff828c8012e2f0>] iommu_set_interrupt+0x97/0x10f (XEN) [<ffff828c8012e4a2>] init_vtd_hw+0x13a/0x2d1 (XEN) [<ffff828c8012fb38>] intel_vtd_setup+0x332/0x4bd (XEN) [<ffff828c8012be18>] iommu_setup+0x2d/0xf5 (XEN) [<ffff828c80222ca8>] __start_xen+0x457d/0x4895 (XEN) (XEN) Pagetable walk from 0000000000000044: (XEN) L4[0x000] = 000000007f706063 5555555555555555 (XEN) L3[0x000] = 000000007e6f1063 5555555555555555 (XEN) L2[0x000] = 000000007e6f0063 5555555555555555 (XEN) L1[0x000] = 0000000000000000 ffffffffffffffff (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) FATAL PAGE FAULT (XEN) [error_code=0000] (XEN) Faulting linear address: 0000000000000044 (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Kouya Shimura Sent: Wednesday, February 11, 2009 7:00 PM To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH] fix iommu interrupt setup iommu is disabled since cset 19175:ab514cfbcdc5 with the following message: (XEN) [VT-D]iommu.c:890:d32767 IOMMU: can''t request irq (XEN) [VT-D]iommu.c:1686:d32767 IOMMU: interrupt setup failed (XEN) I/O virtualisation disabled This patch fixes it. - rename request_irq to request_vector, no conversion by irq_to_vector(irq) - set vector_to_iommu[vector] before calling request_vector since null pointer exceptions occurs - some cleanups Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I''m getting the same bug. -Alex (XEN) ----[ Xen-3.4-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e008:[<ffff828c8011b62f>] check_lock+0x19/0x4e (XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor (XEN) rax: 0000000000000001 rbx: 0000000000000040 rcx: 0000000000000001 (XEN) rdx: 0000000000000082 rsi: 0000000000000001 rdi: 0000000000000044 (XEN) rbp: ffff828c80277c58 rsp: ffff828c80277c58 r8: 0000000000000005 (XEN) r9: 0000000000000001 r10: 0000000000000001 r11: ffff828c8028e360 (XEN) r12: 0000000000000082 r13: 0000000000000282 r14: 0000000000000090 (XEN) r15: ffff83013bfba430 cr0: 000000008005003b cr4: 00000000000026f0 (XEN) cr3: 00000000bd47c000 cr2: 0000000000000044 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Xen stack trace from rsp=ffff828c80277c58: (XEN) ffff828c80277c78 ffff828c8011b7aa 0000000000000000 0000000000000040 (XEN) ffff828c80277c98 ffff828c8012e223 ffff828c802a1c00 ffff828c802a1c24 (XEN) ffff828c80277ca8 ffff828c8012e282 ffff828c80277ce8 ffff828c80147e90 (XEN) ffff828c80277ce8 00000000fffffff4 0000000000000090 ffff828c8012e938 (XEN) ffff828c801e31cd ffff83013bff1f90 ffff828c80277d28 ffff828c801483be (XEN) ffff83013bfba430 0000000000000090 ffff83013bff1f90 0000000000004800 (XEN) ffff83013bff1f90 ffff828c8029d400 ffff828c80277d68 ffff828c8012e5ef (XEN) ffff828c80277d48 0000000000000003 ffff83013bff1f90 0000000000000282 (XEN) ffff83013bff16f0 0000000000100000 ffff828c80277d98 ffff828c8012e7a1 (XEN) 0000000000000003 ffff83013bfba330 ffff828c8020c930 0000000000000020 (XEN) ffff828c80277de8 ffff828c8012fe48 ffff828c80277dd8 ffff828c8012a2e9 (XEN) 0000000000000002 000100018020a4c0 0001000100010001 00000000ffffffed (XEN) ffff828c8022fc08 0000000000000003 ffff828c80277e08 ffff828c8012c008 (XEN) ffff828c80277e08 ffff828c8022faf8 ffff828c80277f18 ffff828c80223d09 (XEN) 0000000000000000 0000000000000000 0000000000000000 ffff828c8020f665 (XEN) ffffffffc0270000 ffff8300bd47cff8 ffff8300bd47dff8 000000000008bf50 (XEN) 0000000000000000 0000000000000000 0000000000000000 ffff83000008bfc0 (XEN) ffff83000008bf50 0000000000cc3c00 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000800000000 000000010000006e (XEN) Xen call trace: (XEN) [<ffff828c8011b62f>] check_lock+0x19/0x4e (XEN) [<ffff828c8011b7aa>] _spin_lock_irqsave+0x21/0x3f (XEN) [<ffff828c8012e223>] dma_msi_unmask+0x2a/0x4b (XEN) [<ffff828c8012e282>] dma_msi_startup+0x9/0x10 (XEN) [<ffff828c80147e90>] setup_irq_vector+0x73/0x99 (XEN) [<ffff828c801483be>] request_irq_vector+0x6c/0x9a (XEN) [<ffff828c8012e5ef>] iommu_set_interrupt+0x97/0x10f (XEN) [<ffff828c8012e7a1>] init_vtd_hw+0x13a/0x2d1 (XEN) [<ffff828c8012fe48>] intel_vtd_setup+0x330/0x4bb (XEN) [<ffff828c8012c008>] iommu_setup+0x2d/0xf5 (XEN) [<ffff828c80223d09>] __start_xen+0x463f/0x4956 (XEN) (XEN) Pagetable walk from 0000000000000044: (XEN) L4[0x000] = 000000013bff0063 5555555555555555 (XEN) L3[0x000] = 000000013bfef063 5555555555555555 (XEN) L2[0x000] = 000000013bfee063 5555555555555555 (XEN) L1[0x000] = 0000000000000000 ffffffffffffffff (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) FATAL PAGE FAULT (XEN) [error_code=0000] (XEN) Faulting linear address: 0000000000000044 (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Allen, this is because the register_lock is not always called with irq disabled. Seems it is called with spin_lock(), instead of spin_lock_irqsave() in queue_invalidate_wait(). But I''m a bit curios why intel_vtd_setup() will be called after queue_invalidate_wait(). Thanks Yunhong Jiang xen-devel-bounces@lists.xensource.com <> wrote:> I''m getting the same bug. > -Alex > > (XEN) ----[ Xen-3.4-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: > 0 (XEN) RIP: e008:[<ffff828c8011b62f>] check_lock+0x19/0x4e > (XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor > (XEN) rax: 0000000000000001 rbx: 0000000000000040 rcx: 0000000000000001 > (XEN) rdx: 0000000000000082 rsi: 0000000000000001 rdi: 0000000000000044 > (XEN) rbp: ffff828c80277c58 rsp: ffff828c80277c58 r8: 0000000000000005 > (XEN) r9: 0000000000000001 r10: 0000000000000001 r11: ffff828c8028e360 > (XEN) r12: 0000000000000082 r13: 0000000000000282 r14: 0000000000000090 > (XEN) r15: ffff83013bfba430 cr0: 000000008005003b cr4: 00000000000026f0 > (XEN) cr3: 00000000bd47c000 cr2: 0000000000000044 > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 > (XEN) Xen stack trace from rsp=ffff828c80277c58: > (XEN) ffff828c80277c78 ffff828c8011b7aa 0000000000000000 0000000000000040 > (XEN) ffff828c80277c98 ffff828c8012e223 ffff828c802a1c00 ffff828c802a1c24 > (XEN) ffff828c80277ca8 ffff828c8012e282 ffff828c80277ce8 ffff828c80147e90 > (XEN) ffff828c80277ce8 00000000fffffff4 0000000000000090 ffff828c8012e938 > (XEN) ffff828c801e31cd ffff83013bff1f90 ffff828c80277d28 ffff828c801483be > (XEN) ffff83013bfba430 0000000000000090 ffff83013bff1f90 0000000000004800 > (XEN) ffff83013bff1f90 ffff828c8029d400 ffff828c80277d68 ffff828c8012e5ef > (XEN) ffff828c80277d48 0000000000000003 ffff83013bff1f90 0000000000000282 > (XEN) ffff83013bff16f0 0000000000100000 ffff828c80277d98 ffff828c8012e7a1 > (XEN) 0000000000000003 ffff83013bfba330 ffff828c8020c930 0000000000000020 > (XEN) ffff828c80277de8 ffff828c8012fe48 ffff828c80277dd8 ffff828c8012a2e9 > (XEN) 0000000000000002 000100018020a4c0 0001000100010001 00000000ffffffed > (XEN) ffff828c8022fc08 0000000000000003 ffff828c80277e08 ffff828c8012c008 > (XEN) ffff828c80277e08 ffff828c8022faf8 ffff828c80277f18 ffff828c80223d09 > (XEN) 0000000000000000 0000000000000000 0000000000000000 ffff828c8020f665 > (XEN) ffffffffc0270000 ffff8300bd47cff8 ffff8300bd47dff8 000000000008bf50 > (XEN) 0000000000000000 0000000000000000 0000000000000000 ffff83000008bfc0 > (XEN) ffff83000008bf50 0000000000cc3c00 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000800000000 000000010000006e > (XEN) Xen call trace: > (XEN) [<ffff828c8011b62f>] check_lock+0x19/0x4e > (XEN) [<ffff828c8011b7aa>] _spin_lock_irqsave+0x21/0x3f > (XEN) [<ffff828c8012e223>] dma_msi_unmask+0x2a/0x4b > (XEN) [<ffff828c8012e282>] dma_msi_startup+0x9/0x10 > (XEN) [<ffff828c80147e90>] setup_irq_vector+0x73/0x99 > (XEN) [<ffff828c801483be>] request_irq_vector+0x6c/0x9a > (XEN) [<ffff828c8012e5ef>] iommu_set_interrupt+0x97/0x10f > (XEN) [<ffff828c8012e7a1>] init_vtd_hw+0x13a/0x2d1 > (XEN) [<ffff828c8012fe48>] intel_vtd_setup+0x330/0x4bb > (XEN) [<ffff828c8012c008>] iommu_setup+0x2d/0xf5 > (XEN) [<ffff828c80223d09>] __start_xen+0x463f/0x4956 (XEN) > (XEN) Pagetable walk from 0000000000000044: > (XEN) L4[0x000] = 000000013bff0063 5555555555555555 > (XEN) L3[0x000] = 000000013bfef063 5555555555555555 > (XEN) L2[0x000] = 000000013bfee063 5555555555555555 > (XEN) L1[0x000] = 0000000000000000 ffffffffffffffff (XEN) > (XEN) **************************************** > (XEN) Panic on CPU 0: > (XEN) FATAL PAGE FAULT > (XEN) [error_code=0000] > (XEN) Faulting linear address: 0000000000000044 > (XEN) **************************************** > (XEN) > (XEN) Reboot in five seconds... > (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. > > _______________________________________________ > 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
Sorry, seems queue_invalidate_wait() has irq disabled also :$ So there should have other reason for it. -- Yunhong Jiang xen-devel-bounces@lists.xensource.com <> wrote:> Allen, this is because the register_lock is not always called > with irq disabled. Seems it is called with spin_lock(), > instead of spin_lock_irqsave() in queue_invalidate_wait(). > > But I''m a bit curios why intel_vtd_setup() will be called > after queue_invalidate_wait(). > > Thanks > Yunhong Jiang > > xen-devel-bounces@lists.xensource.com <> wrote: >> I''m getting the same bug. >> -Alex >> >> (XEN) ----[ Xen-3.4-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: >> 0 (XEN) RIP: e008:[<ffff828c8011b62f>] check_lock+0x19/0x4e >> (XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor >> (XEN) rax: 0000000000000001 rbx: 0000000000000040 rcx: 0000000000000001 >> (XEN) rdx: 0000000000000082 rsi: 0000000000000001 rdi: 0000000000000044 >> (XEN) rbp: ffff828c80277c58 rsp: ffff828c80277c58 r8: 0000000000000005 >> (XEN) r9: 0000000000000001 r10: 0000000000000001 r11: ffff828c8028e360 >> (XEN) r12: 0000000000000082 r13: 0000000000000282 r14: 0000000000000090 >> (XEN) r15: ffff83013bfba430 cr0: 000000008005003b cr4: 00000000000026f0 >> (XEN) cr3: 00000000bd47c000 cr2: 0000000000000044 >> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 >> (XEN) Xen stack trace from rsp=ffff828c80277c58: >> (XEN) ffff828c80277c78 ffff828c8011b7aa 0000000000000000 >> 0000000000000040 (XEN) ffff828c80277c98 ffff828c8012e223 >> ffff828c802a1c00 ffff828c802a1c24 (XEN) ffff828c80277ca8 >> ffff828c8012e282 ffff828c80277ce8 ffff828c80147e90 (XEN) >> ffff828c80277ce8 00000000fffffff4 0000000000000090 ffff828c8012e938 (XEN) >> ffff828c801e31cd ffff83013bff1f90 ffff828c80277d28 ffff828c801483be (XEN) >> ffff83013bfba430 0000000000000090 ffff83013bff1f90 0000000000004800 (XEN) >> ffff83013bff1f90 ffff828c8029d400 ffff828c80277d68 ffff828c8012e5ef (XEN) >> ffff828c80277d48 0000000000000003 ffff83013bff1f90 0000000000000282 (XEN) >> ffff83013bff16f0 0000000000100000 ffff828c80277d98 ffff828c8012e7a1 (XEN) >> 0000000000000003 ffff83013bfba330 ffff828c8020c930 0000000000000020 (XEN) >> ffff828c80277de8 ffff828c8012fe48 ffff828c80277dd8 ffff828c8012a2e9 (XEN) >> 0000000000000002 000100018020a4c0 0001000100010001 00000000ffffffed (XEN) >> ffff828c8022fc08 0000000000000003 ffff828c80277e08 ffff828c8012c008 (XEN) >> ffff828c80277e08 ffff828c8022faf8 ffff828c80277f18 ffff828c80223d09 (XEN) >> 0000000000000000 0000000000000000 0000000000000000 ffff828c8020f665 (XEN) >> ffffffffc0270000 ffff8300bd47cff8 ffff8300bd47dff8 000000000008bf50 (XEN) >> 0000000000000000 0000000000000000 0000000000000000 ffff83000008bfc0 (XEN) >> ffff83000008bf50 0000000000cc3c00 0000000000000000 0000000000000000 (XEN) >> 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) >> 0000000000000000 0000000000000000 0000000800000000 000000010000006e (XEN) >> Xen call trace: (XEN) [<ffff828c8011b62f>] check_lock+0x19/0x4e (XEN) >> [<ffff828c8011b7aa>] _spin_lock_irqsave+0x21/0x3f (XEN) >> [<ffff828c8012e223>] dma_msi_unmask+0x2a/0x4b (XEN) >> [<ffff828c8012e282>] dma_msi_startup+0x9/0x10 (XEN) >> [<ffff828c80147e90>] setup_irq_vector+0x73/0x99 (XEN) >> [<ffff828c801483be>] request_irq_vector+0x6c/0x9a (XEN) >> [<ffff828c8012e5ef>] iommu_set_interrupt+0x97/0x10f (XEN) >> [<ffff828c8012e7a1>] init_vtd_hw+0x13a/0x2d1 (XEN) [<ffff828c8012fe48>] >> intel_vtd_setup+0x330/0x4bb (XEN) [<ffff828c8012c008>] >> iommu_setup+0x2d/0xf5 (XEN) [<ffff828c80223d09>] >> __start_xen+0x463f/0x4956 (XEN) (XEN) Pagetable walk from 0000000000000044: >> (XEN) L4[0x000] = 000000013bff0063 5555555555555555 >> (XEN) L3[0x000] = 000000013bfef063 5555555555555555 >> (XEN) L2[0x000] = 000000013bfee063 5555555555555555 >> (XEN) L1[0x000] = 0000000000000000 ffffffffffffffff (XEN) >> (XEN) **************************************** >> (XEN) Panic on CPU 0: >> (XEN) FATAL PAGE FAULT >> (XEN) [error_code=0000] >> (XEN) Faulting linear address: 0000000000000044 >> (XEN) **************************************** >> (XEN) >> (XEN) Reboot in five seconds... >> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. >> >> _______________________________________________ >> 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
It is because in iommu_set_interrupt(), the vector_to_iommu[] is setup after request_irq(), while request_irq() will call start_up(), which will need the vector_to_iommu[]. So maybe we can setup the vector_to_iommup[] before request_irq(). Thanks Yunhong Jiang Jiang, Yunhong <> wrote:> Sorry, seems queue_invalidate_wait() has irq disabled also :$ > So there should have other reason for it. > > -- Yunhong Jiang > > xen-devel-bounces@lists.xensource.com <> wrote: >> Allen, this is because the register_lock is not always called >> with irq disabled. Seems it is called with spin_lock(), >> instead of spin_lock_irqsave() in queue_invalidate_wait(). >> >> But I''m a bit curios why intel_vtd_setup() will be called >> after queue_invalidate_wait(). >> >> Thanks >> Yunhong Jiang >> >> xen-devel-bounces@lists.xensource.com <> wrote: >>> I''m getting the same bug. >>> -Alex >>> >>> (XEN) ----[ Xen-3.4-unstable x86_64 debug=y Not tainted ]---- (XEN) >>> CPU: 0 (XEN) RIP: e008:[<ffff828c8011b62f>] check_lock+0x19/0x4e >>> (XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor >>> (XEN) rax: 0000000000000001 rbx: 0000000000000040 rcx: >>> 0000000000000001 (XEN) rdx: 0000000000000082 rsi: 0000000000000001 >>> rdi: 0000000000000044 (XEN) rbp: ffff828c80277c58 rsp: ffff828c80277c58 >>> r8: 0000000000000005 (XEN) r9: 0000000000000001 r10: 0000000000000001 >>> r11: ffff828c8028e360 (XEN) r12: 0000000000000082 r13: 0000000000000282 >>> r14: 0000000000000090 (XEN) r15: ffff83013bfba430 cr0: 000000008005003b >>> cr4: 00000000000026f0 (XEN) cr3: 00000000bd47c000 cr2: 0000000000000044 >>> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 >>> (XEN) Xen stack trace from rsp=ffff828c80277c58: >>> (XEN) ffff828c80277c78 ffff828c8011b7aa 0000000000000000 >>> 0000000000000040 (XEN) ffff828c80277c98 ffff828c8012e223 >>> ffff828c802a1c00 ffff828c802a1c24 (XEN) ffff828c80277ca8 >>> ffff828c8012e282 ffff828c80277ce8 ffff828c80147e90 (XEN) >>> ffff828c80277ce8 00000000fffffff4 0000000000000090 ffff828c8012e938 (XEN) >>> ffff828c801e31cd ffff83013bff1f90 ffff828c80277d28 ffff828c801483be (XEN) >>> ffff83013bfba430 0000000000000090 ffff83013bff1f90 0000000000004800 (XEN) >>> ffff83013bff1f90 ffff828c8029d400 ffff828c80277d68 ffff828c8012e5ef (XEN) >>> ffff828c80277d48 0000000000000003 ffff83013bff1f90 0000000000000282 (XEN) >>> ffff83013bff16f0 0000000000100000 ffff828c80277d98 ffff828c8012e7a1 (XEN) >>> 0000000000000003 ffff83013bfba330 ffff828c8020c930 0000000000000020 (XEN) >>> ffff828c80277de8 ffff828c8012fe48 ffff828c80277dd8 ffff828c8012a2e9 (XEN) >>> 0000000000000002 000100018020a4c0 0001000100010001 00000000ffffffed (XEN) >>> ffff828c8022fc08 0000000000000003 ffff828c80277e08 ffff828c8012c008 (XEN) >>> ffff828c80277e08 ffff828c8022faf8 ffff828c80277f18 ffff828c80223d09 (XEN) >>> 0000000000000000 0000000000000000 0000000000000000 ffff828c8020f665 (XEN) >>> ffffffffc0270000 ffff8300bd47cff8 ffff8300bd47dff8 000000000008bf50 (XEN) >>> 0000000000000000 0000000000000000 0000000000000000 ffff83000008bfc0 (XEN) >>> ffff83000008bf50 0000000000cc3c00 0000000000000000 0000000000000000 (XEN) >>> 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) >>> 0000000000000000 0000000000000000 0000000800000000 000000010000006e (XEN) >>> Xen call trace: (XEN) [<ffff828c8011b62f>] check_lock+0x19/0x4e (XEN) >>> [<ffff828c8011b7aa>] _spin_lock_irqsave+0x21/0x3f (XEN) >>> [<ffff828c8012e223>] dma_msi_unmask+0x2a/0x4b (XEN) >>> [<ffff828c8012e282>] dma_msi_startup+0x9/0x10 (XEN) >>> [<ffff828c80147e90>] setup_irq_vector+0x73/0x99 (XEN) >>> [<ffff828c801483be>] request_irq_vector+0x6c/0x9a (XEN) >>> [<ffff828c8012e5ef>] iommu_set_interrupt+0x97/0x10f (XEN) >>> [<ffff828c8012e7a1>] init_vtd_hw+0x13a/0x2d1 (XEN) [<ffff828c8012fe48>] >>> intel_vtd_setup+0x330/0x4bb (XEN) [<ffff828c8012c008>] >>> iommu_setup+0x2d/0xf5 (XEN) [<ffff828c80223d09>] >>> __start_xen+0x463f/0x4956 (XEN) (XEN) Pagetable walk from >>> 0000000000000044: (XEN) L4[0x000] = 000000013bff0063 5555555555555555 >>> (XEN) L3[0x000] = 000000013bfef063 5555555555555555 >>> (XEN) L2[0x000] = 000000013bfee063 5555555555555555 >>> (XEN) L1[0x000] = 0000000000000000 ffffffffffffffff (XEN) >>> (XEN) **************************************** >>> (XEN) Panic on CPU 0: >>> (XEN) FATAL PAGE FAULT >>> (XEN) [error_code=0000] >>> (XEN) Faulting linear address: 0000000000000044 >>> (XEN) **************************************** >>> (XEN) >>> (XEN) Reboot in five seconds... >>> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. >>> >>> _______________________________________________ >>> 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
<kouya@jp.fujitsu.com>
2009-Feb-13 01:46 UTC
RE: [Xen-devel] [PATCH] fix iommu interrupt setup
Hi, Attached patch may help. This is extracted from my previous patch. - set vector_to_iommu[vector] before calling request_vector since null pointer exceptions occurs Thanks, Kouya Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> Kay, Allen M writes:> Interrupt handling cleanup in changeset 19195 is causing following failure on my system: > > (XEN) ----[ Xen-3.4-unstable x86_64 debug=y Not tainted ]---- > (XEN) CPU: 0 > (XEN) RIP: e008:[<ffff828c8011b591>] check_lock+0x19/0x4e > (XEN) RFLAGS: 0000000000010046 CONTEXT: hypervisor > (XEN) rax: 0000000000000001 rbx: 0000000000000040 rcx: 0000000000000001 > (XEN) rdx: 0000000000000082 rsi: 0000000000000001 rdi: 0000000000000044 > (XEN) rbp: ffff828c80277c58 rsp: ffff828c80277c58 r8: 0000000000000005 > (XEN) r9: 0000000000000001 r10: 0000000000000001 r11: 0000000000000000 > (XEN) r12: 0000000000000082 r13: 0000000000000282 r14: 0000000000000090 > (XEN) r15: ffff83007f2c4160 cr0: 000000008005003b cr4: 00000000000026f0 > (XEN) cr3: 000000007f47c000 cr2: 0000000000000044 > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 > (XEN) Xen stack trace from rsp=ffff828c80277c58: > (XEN) ffff828c80277c78 ffff828c8011b70c 0000000000000000 0000000000000040 > (XEN) ffff828c80277c98 ffff828c8012df24 ffff828c802a1c00 ffff828c802a1c24 > (XEN) ffff828c80277ca8 ffff828c8012df83 ffff828c80277ce8 ffff828c80147cc0 > (XEN) ffff828c80277ce8 00000000fffffff4 0000000000000090 ffff828c8012e639 > (XEN) ffff828c801e2191 ffff83007f4d9df0 ffff828c80277d28 ffff828c801481fa > (XEN) ffff83007f2c4160 0000000000000090 ffff83007f4d9df0 0000000000004800 > (XEN) ffff83007f4d9df0 ffff828c8029d400 ffff828c80277d68 ffff828c8012e2f0 > (XEN) ffff828c80277d48 0000000000000000 ffff83007f4d9df0 0000000000000282 > (XEN) ffff83007f6df130 0000000000100000 ffff828c80277d98 ffff828c8012e4a2 > (XEN) 0000000000000000 ffff83007f4d9df0 ffff828c8020b8b0 0000000000000020 > (XEN) ffff828c80277de8 ffff828c8012fb38 ffff828c80277dd8 ffff828c8012a183 > (XEN) 0000000000000004 00010001802093c0 0001000100010001 00000000ffffffed > (XEN) ffff828c8022ec08 0000000000000017 ffff828c80277e08 ffff828c8012be18 > (XEN) ffff828c80277e08 ffff828c8022eaf8 ffff828c80277f18 ffff828c80222ca8 > (XEN) 0000000000000000 0000000000000000 0000000000000000 ffff828c8020e675 > (XEN) ffffffffc0270000 ffff83007f47cff8 ffff83007f47dff8 000000000020e610 > (XEN) 000000000008bf60 0000000000000000 0000000000000000 0000000000000000 > (XEN) ffff83000008bfc0 ffff83000008bf60 0000000000b0c800 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000800000000 000000010000006e > (XEN) Xen call trace: > (XEN) [<ffff828c8011b591>] check_lock+0x19/0x4e > (XEN) [<ffff828c8011b70c>] _spin_lock_irqsave+0x21/0x3f > (XEN) [<ffff828c8012df24>] dma_msi_unmask+0x2a/0x4b > (XEN) [<ffff828c8012df83>] dma_msi_startup+0x9/0x10 > (XEN) [<ffff828c80147cc0>] setup_irq_vector+0x73/0x99 > (XEN) [<ffff828c801481fa>] request_irq_vector+0x6c/0x9a > (XEN) [<ffff828c8012e2f0>] iommu_set_interrupt+0x97/0x10f > (XEN) [<ffff828c8012e4a2>] init_vtd_hw+0x13a/0x2d1 > (XEN) [<ffff828c8012fb38>] intel_vtd_setup+0x332/0x4bd > (XEN) [<ffff828c8012be18>] iommu_setup+0x2d/0xf5 > (XEN) [<ffff828c80222ca8>] __start_xen+0x457d/0x4895 > (XEN) > (XEN) Pagetable walk from 0000000000000044: > (XEN) L4[0x000] = 000000007f706063 5555555555555555 > (XEN) L3[0x000] = 000000007e6f1063 5555555555555555 > (XEN) L2[0x000] = 000000007e6f0063 5555555555555555 > (XEN) L1[0x000] = 0000000000000000 ffffffffffffffff > (XEN) > (XEN) **************************************** > (XEN) Panic on CPU 0: > (XEN) FATAL PAGE FAULT > (XEN) [error_code=0000] > (XEN) Faulting linear address: 0000000000000044 > (XEN) **************************************** > (XEN) > (XEN) Reboot in five seconds... > > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Kouya Shimura > Sent: Wednesday, February 11, 2009 7:00 PM > To: xen-devel@lists.xensource.com > Subject: [Xen-devel] [PATCH] fix iommu interrupt setup > > iommu is disabled since cset 19175:ab514cfbcdc5 with the following message: > > (XEN) [VT-D]iommu.c:890:d32767 IOMMU: can''t request irq > (XEN) [VT-D]iommu.c:1686:d32767 IOMMU: interrupt setup failed > (XEN) I/O virtualisation disabled > > This patch fixes it. > - rename request_irq to request_vector, no conversion by irq_to_vector(irq) > - set vector_to_iommu[vector] before calling request_vector > since null pointer exceptions occurs > - some cleanups > > Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12/02/2009 22:17, "Kay, Allen M" <allen.m.kay@intel.com> wrote:> Interrupt handling cleanup in changeset 19195 is causing following failure on > my system: > > (XEN) ----[ Xen-3.4-unstable x86_64 debug=y Not tainted ]----The guy you want to complain to is Espen, not Kouya. These interrupt cleanups have not gone smoothly. I''ll give it a while longer but I will rip them all back out if the situation doesn''t get better by next week. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13/02/2009 01:46, "kouya@jp.fujitsu.com" <kouya@jp.fujitsu.com> wrote:> Hi, > > Attached patch may help. This is extracted from my previous patch. > - set vector_to_iommu[vector] before calling request_vector > since null pointer exceptions occursThanks Kouya, let''s hope this puts the issues to rest. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
[Keir Fraser]> On 12/02/2009 22:17, "Kay, Allen M" <allen.m.kay@intel.com> wrote: >> Interrupt handling cleanup in changeset 19195 is causing following >> failure on my system: >> >> (XEN) ----[ Xen-3.4-unstable x86_64 debug=y Not tainted ]----> The guy you want to complain to is Espen, not Kouya.It''s always nice when someone else accidentally gets the blame. :)> These interrupt cleanups have not gone smoothly. I''ll give it a > while longer but I will rip them all back out if the situation > doesn''t get better by next week.Things have not gone smoothly at all. Hopefully Kouya''s patch will sort out that IOMMU issue. And hopefully I can get my hands on a new Tylersburg system so that I can test out all the VT-d interrupt remapping stuff myself. eSk _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13/02/2009 11:33, "Espen Skoglund" <espen.skoglund@netronome.com> wrote:>> These interrupt cleanups have not gone smoothly. I''ll give it a >> while longer but I will rip them all back out if the situation >> doesn''t get better by next week. > > Things have not gone smoothly at all. Hopefully Kouya''s patch will > sort out that IOMMU issue. And hopefully I can get my hands on a new > Tylersburg system so that I can test out all the VT-d interrupt > remapping stuff myself.By the way, one of your other patches got reverted since it broke booting on a bunch of systems. It was applied as c/s 19178 and reverted as c/s 19182. It was the one that separates IOAPIC mgmt from vector mgmt. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
[Keir Fraser]> On 13/02/2009 11:33, "Espen Skoglund" <espen.skoglund@netronome.com> wrote: >>> These interrupt cleanups have not gone smoothly. I''ll give it a >>> while longer but I will rip them all back out if the situation >>> doesn''t get better by next week. >> >> Things have not gone smoothly at all. Hopefully Kouya''s patch will >> sort out that IOMMU issue. And hopefully I can get my hands on a >> new Tylersburg system so that I can test out all the VT-d interrupt >> remapping stuff myself.> By the way, one of your other patches got reverted since it broke > booting on a bunch of systems. It was applied as c/s 19178 and > reverted as c/s 19182. It was the one that separates IOAPIC mgmt > from vector mgmt.Yes. I noticed. Was going to ask about more info on this one. Is there some bugzilla entry or something that gives some more detail about what the problems were? (I''m a bugzilla newbie and don''t follow xen-bugs@ at all.) eSk _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13/02/2009 11:57, "Espen Skoglund" <espen.skoglund@netronome.com> wrote:>> By the way, one of your other patches got reverted since it broke >> booting on a bunch of systems. It was applied as c/s 19178 and >> reverted as c/s 19182. It was the one that separates IOAPIC mgmt >> from vector mgmt. > > Yes. I noticed. Was going to ask about more info on this one. Is > there some bugzilla entry or something that gives some more detail > about what the problems were? (I''m a bugzilla newbie and don''t follow > xen-bugs@ at all.)Hangs when bringing up the disc controller (whether SCSI or IDE) with command timeouts and the like which generally point to broken interrupts. When I said it didn''t work on a ''wide range'' of systems, we didn''t actually find a single system it *did* work on! We must have tested on at least four separate systems with 100% failure on those. I reckon you should be able to repro it yourself pretty easily. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel