On Tue, 31 Jan 2012, Chris Wright <chrisw <at> sous-sol.org> wrote: >> >Well, the lspci dump in the bugzilla report doesn't show a device >> >w/BDF=0b:00.1; >> >so, if the SATA device (which is 0b:00.0) is spitting out 0b:00.1 >> >as the source >> >of any of its DMA packets, the IOMMU will fault on it, since >> >0b:00.1 didn't >> >request DMA mappings (0b:00.0 did). >> >I semi-recall someone else reporting this 'feature' on this list. >> >Wonder if pci-quirk has to filter this case (0b:00.0 on this system >> means >> >map for 0b:00.0 & 0b:00.1 -- ick!) >> > It would seem that there are multiple Marvell 88SE91xx controllers that use xx:00.0 and xx:00.1 and only report xx:00.0. I've got the same issue on a 88SE9172 and can't simply move to a different controller without buying more hardware. Besides, this should work ;) Is this an issue of a missing entry in some ACPI table? It's been suggested that a pci-quirk could handle this by mapping both the .0 and .1 entry when the .0 shows up, but what isn't clear to me is where this should be done. Is it a case of setting the "present" bit for an existing context entry, or adding an additional context entry? AC. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
