BUG in drivers/dma/ioat/dma_v2.c:314
in [Kernel]
|
Prev: avoid return NULL on root rb_node in rb_next/rb_prev in lib/rbtree.c
Next: arch/x86/kernel/cpu/mtrr/cleanup.c: Use ";" not "," to terminate statements
From: Dan Williams on 30 Jun 2010 15:50 On 6/30/2010 11:43 AM, Woodhouse, David wrote: > On Wed, 2010-06-30 at 19:26 +0100, Chris Li wrote: >> >> The delta seems to be this line: >> ioatdma 0000:00:0f.0: ioat2_set_chainaddr: chainaddr: ffffe000 > > That's a reasonable address if the IOMMU is enabled. We start at 4GiB > and work down, so that's the second page given out (or the first 8KiB > chunk). > > It looks like the DMA is going AWOL causing the initialisation to > fail... but it's interesting that there are no DMA faults reported by > the IOMMU. > It seems the 5400 has a dedicated remapping engine just for the DMA device [1], is Linux only setting up the iommus per root port (which the DMA bypasses)?? From the dmesg: > IOMMU 0: reg_base_addr fe710000 ver 1:0 cap 900000c2f0462 ecap e01 > DMAR: DRHD base: 0x000000fe714000 flags: 0x0 > IOMMU 1: reg_base_addr fe714000 ver 1:0 cap 900000c2f0462 ecap e01 > DMAR: DRHD base: 0x000000fe719000 flags: 0x0 > IOMMU 2: reg_base_addr fe719000 ver 1:0 cap 900000c2f0462 ecap e01 > DMAR: DRHD base: 0x000000fe718000 flags: 0x1 > IOMMU 3: reg_base_addr fe718000 ver 1:0 cap 900000c2f0462 ecap e01 Where we expect bit 54 to be set for the DMA iommu, and it does not appear to show up. -- Dan [1]: http://www.intel.com/Assets/PDF/datasheet/318610.pdf (Section 3.11.2 page 256) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Woodhouse on 30 Jun 2010 16:10 On Wed, 2010-06-30 at 20:40 +0100, Williams, Dan J wrote: > From the dmesg: > > IOMMU 0: reg_base_addr fe710000 ver 1:0 cap 900000c2f0462 ecap e01 > > DMAR: DRHD base: 0x000000fe714000 flags: 0x0 > > IOMMU 1: reg_base_addr fe714000 ver 1:0 cap 900000c2f0462 ecap e01 > > DMAR: DRHD base: 0x000000fe719000 flags: 0x0 > > IOMMU 2: reg_base_addr fe719000 ver 1:0 cap 900000c2f0462 ecap e01 > > DMAR: DRHD base: 0x000000fe718000 flags: 0x1 > > IOMMU 3: reg_base_addr fe718000 ver 1:0 cap 900000c2f0462 ecap e01 > > Where we expect bit 54 to be set for the DMA iommu, and it does not > appear to show up. So the BIOS is lying to us about which PCI devices are attached to which IOMMU? -- David Woodhouse Open Source Technology Centre David.Woodhouse(a)intel.com Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dan Williams on 30 Jun 2010 17:50 On 6/30/2010 1:02 PM, Woodhouse, David wrote: > On Wed, 2010-06-30 at 20:40 +0100, Williams, Dan J wrote: >> From the dmesg: >>> IOMMU 0: reg_base_addr fe710000 ver 1:0 cap 900000c2f0462 ecap e01 >>> DMAR: DRHD base: 0x000000fe714000 flags: 0x0 >>> IOMMU 1: reg_base_addr fe714000 ver 1:0 cap 900000c2f0462 ecap e01 >>> DMAR: DRHD base: 0x000000fe719000 flags: 0x0 >>> IOMMU 2: reg_base_addr fe719000 ver 1:0 cap 900000c2f0462 ecap e01 >>> DMAR: DRHD base: 0x000000fe718000 flags: 0x1 >>> IOMMU 3: reg_base_addr fe718000 ver 1:0 cap 900000c2f0462 ecap e01 >> >> Where we expect bit 54 to be set for the DMA iommu, and it does not >> appear to show up. > > So the BIOS is lying to us about which PCI devices are attached to which > IOMMU? > It certainly looks that way, or it is at least ignoring any iommu that is not associated with a root port. I have a supermicro x7dwn+ board here with the same 5400 series chipset that "does the right thing (TM)": > [ 0.052101] DMAR: Host address width 38 > [ 0.053004] DMAR: DRHD base: 0x000000fe710000 flags: 0x0 > [ 0.054008] IOMMU fe710000: ver 1:0 cap 900800c2f0462 ecap e01 > [ 0.055003] DMAR: DRHD base: 0x000000fe712000 flags: 0x0 > [ 0.056012] IOMMU fe712000: ver 1:0 cap 900800c2f0462 ecap e01 > [ 0.057003] DMAR: DRHD base: 0x000000fe714000 flags: 0x0 > [ 0.058007] IOMMU fe714000: ver 1:0 cap 900800c2f0462 ecap e01 > [ 0.059003] DMAR: DRHD base: 0x000000fe716000 flags: 0x0 > [ 0.060006] IOMMU fe716000: ver 1:0 cap 900800c2f0462 ecap e01 > [ 0.061003] DMAR: DRHD base: 0x000000fe719000 flags: 0x0 > [ 0.062007] IOMMU fe719000: ver 1:0 cap 900800c2f0462 ecap e01 > [ 0.063003] DMAR: DRHD base: 0x000000fe71a000 flags: 0x0 > [ 0.064011] IOMMU fe71a000: ver 1:0 cap 4900800c2f0462 ecap e01 Here is our DMA iommu. > [ 0.065003] DMAR: DRHD base: 0x000000fe718000 flags: 0x1 > [ 0.066007] IOMMU fe718000: ver 1:0 cap 900800c2f0462 ecap e01 > [ 0.067003] DMAR: RMRR base: 0x000000bff6b000 end: 0x000000bff72fff > [ 0.068003] DMAR: No ATSR found [..] > # modprobe ioatdma > [ 36.311819] dca service started, version 1.12.1 > [ 36.334934] ioatdma: Intel(R) QuickData Technology Driver 4.00 > [ 36.341245] alloc irq_desc for 57 on node -1 > [ 36.342154] alloc kstat_irqs on node -1 > [ 36.350418] ioatdma 0000:00:0f.0: PCI INT A -> GSI 57 (level, low) -> IRQ 57 > [ 36.357916] ioatdma 0000:00:0f.0: setting latency timer to 64 > [ 36.364091] alloc irq_desc for 104 on node -1 > [ 36.365056] alloc kstat_irqs on node -1 > [ 36.373334] ioatdma 0000:00:0f.0: irq 104 for MSI/MSI-X > [ 36.378957] alloc irq_desc for 105 on node -1 > [ 36.379954] alloc kstat_irqs on node -1 > [ 36.388203] ioatdma 0000:00:0f.0: irq 105 for MSI/MSI-X > [ 36.400150] alloc irq_desc for 106 on node -1 > [ 36.401147] alloc kstat_irqs on node -1 > [ 36.409417] ioatdma 0000:00:0f.0: irq 106 for MSI/MSI-X > [ 36.415036] alloc irq_desc for 107 on node -1 > [ 36.416032] alloc kstat_irqs on node -1 > [ 36.424304] ioatdma 0000:00:0f.0: irq 107 for MSI/MSI-X > [ 36.430263] ioatdma 0000:00:0f.0: APICID_TAG_MAP set incorrectly by BIOS, disabling DCA ....and here is the ioatdma driver coming up correctly (albeit with a dca misconfiguration) I don't see a way around this beyond blacklisting this (platform, vt-d setting, driver) combination. Is there a quirk infrastructure for this sort of problem? Chris, is there a BIOS update available for your platform? -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Chris Li on 30 Jun 2010 18:00 On Wed, Jun 30, 2010 at 2:44 PM, Dan Williams <dan.j.williams(a)intel.com> wrote: > > Chris, is there a BIOS update available for your platform? You mean the EFI firmware update? Nope. Do you think loading linux via EFI instead of boot camp (BIOS) will help? Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dan Williams on 30 Jun 2010 18:10
On 6/30/2010 2:59 PM, Chris Li wrote: > On Wed, Jun 30, 2010 at 2:44 PM, Dan Williams<dan.j.williams(a)intel.com> wrote: >> >> Chris, is there a BIOS update available for your platform? > > You mean the EFI firmware update? Nope. > > Do you think loading linux via EFI instead of boot camp (BIOS) will help? > ....only if the EFI boot process hands Linux a correct (i.e. complete) DMAR table. I suspect native EFI and legacy BIOS boot would still end up passing the same table, but I don't know for sure. -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |