On Thu, 2014-04-10 at 09:15 +0200, Joerg Roedel wrote: > [+ David, VT-d maintainer ] > > Jiang, David, can you please have a look into this issue? > > > > >> > > > > DMAR:[fault reason 02] Present bit in context entry is clear > > > >> > > > > dmar: DRHD: handling fault status reg 602 > > > >> > > > > dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000 That "Present bit in context entry is clear" fault means that we have not set up *any* mappings for this PCI device… on this IOMMU. > > Yes, specifically (finally done bisecting): > > > > commit 2e45528930388658603ea24d49cf52867b928d3e > > Author: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx> > > Date: Wed Feb 19 14:07:36 2014 +0800 > > > > iommu/vt-d: Unify the way to process DMAR device scope array This commit is about how we decide which IOMMU a given PCI device is attached to. Thus, my first guess would be that we are quite happily setting up the requested DMA maps on the *wrong* IOMMU, and then taking faults when the device actually tries to do DMA. However, I'm not 100% convinced of that. The fault address looks suspiciously like a true physical address, not a virtual bus address of the type that we'd normally allocate for a dma_map_* operation. Those would start at 0xfffff000 and work downwards, typically. Do you have 'iommu=pt' on the kernel command line? Can I see the full dmesg as this system boots, and also a copy of the DMAR table? We should also rate-limit DMA faults, which would avoid the lockup failure mode. Bjorn, what should an IOMMU driver *do* when it detects that a device is creating an endless stream of DMA faults and isn't aborting the transaction? I can set it to silent so that it just stops *reporting* the DMA faults for that device... and I suppose I can re-enable them when I next see a DMA mapping for it (although actually it'd be better to have a hook to do that on FLR or something like that). But there must be a better answer than that, surely? And I don't want to hack it up locally in *one* specific IOMMU driver, any more than I have to. On a POWER system with EEH, the kernel would end up isolating the offending device completely, and subsequently resetting it... -- David Woodhouse Open Source Technology Centre David.Woodhouse@xxxxxxxxx Intel Corporation
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
