| Message ID | 534BA30B.5040102@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Bjorn Helgaas |
| Headers | show |
On Mon, 2014-04-14 at 16:57 +0800, Jiang Liu wrote: > Hi all, > I guess I found the root cause. It's a bug in matching > device scope, variable 'level' should be decreased when walking up PCI > topology. > Could you please help to test following patch? > Thanks! > Gerry Worked like a charm -- I no longer see all those DMAR messages and the hpsa hard lockup is gone, thanks. Feel free to add my: Reported-and-tested-by: Davidlohr Bueso <davidlohr@hp.com> -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c index f445c10..1f8308c 100644 --- a/drivers/iommu/dmar.c +++ b/drivers/iommu/dmar.c @@ -152,7 +152,7 @@ dmar_alloc_pci_notify_info(struct pci_dev *dev, unsigned long event) info->seg = pci_domain_nr(dev->bus); info->level = level; if (event == BUS_NOTIFY_ADD_DEVICE) { - for (tmp = dev, level--; tmp; tmp = tmp->bus->self) { + for (tmp = dev, level--; tmp; level--, tmp = tmp->bus->self) { info->path[level].device = PCI_SLOT(tmp->devfn);
Hi all, I guess I found the root cause. It's a bug in matching device scope, variable 'level' should be decreased when walking up PCI topology. Could you please help to test following patch? Thanks! Gerry info->path[level].function = PCI_FUNC(tmp->devfn); if (pci_is_root_bus(tmp->bus)) On 2014/4/11 0:19, Davidlohr Bueso wrote: > On Thu, 2014-04-10 at 08:46 +0000, Woodhouse, David wrote: >> 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@linux.intel.com> >>>> 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? > > No. > >> Can I see the full >> dmesg as this system boots, and also a copy of the DMAR table? > > Attaching a dmesg from one of the kernels that boots. It doesn't appear > to have much of the related information... is there any debug config > option I can enable that might give you more data? > -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html