lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 22 May 2010 19:40:43 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Matthew Wilcox <matthew@....cx>, jbarnes@...tuousgeek.org
Cc:	Stefan Richter <stefanr@...6.in-berlin.de>,
	linux-pci@...r.kernel.org, linux1394-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: DMAR:[fault reason 02] Present bit in context entry is clear
 (firewire-ohci)

On Sat, 2010-05-22 at 06:12 -0600, Matthew Wilcox wrote:
> On Sat, May 22, 2010 at 12:26:15PM +0200, Stefan Richter wrote:
> > Hi,
> > 
> > I came across a report of the subject message.  What does it mean; what
> > type of bug should be look for?
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=587178
> > >>>
> > firewire_ohci 0000:04:00.4: PCI INT C -> GSI 16 (level, low) -> IRQ 16
> > firewire_ohci 0000:04:00.4: setting latency timer to 64
> > firewire_ohci: Added fw-ohci device 0000:04:00.4, OHCI version 1.0
> > DRHD: handling fault status reg 2
> > DMAR:[DMA Read] Request device [04:00.0] fault addr fffff000
> > DMAR:[fault reason 02] Present bit in context entry is clear
> > DMAR:[DMA Read] Request device [04:00.0] fault addr fffff000
> > DMAR:[fault reason 02] Present bit in context entry is clear
> > DMAR:[DMA Read] Request device [04:00.0] fault addr fffff000
> > DMAR:[fault reason 02] Present bit in context entry is clear
> > <<<
> > 
> > The log sounds as if this happens during from-device DMA of 04:00.4 into
> > a consistent buffer, yet the fault is logged for device 04:00.0.  The
> > log is from a Dell M4500.  The devices are, according to a web search,
> > 04:00.0 CardBus bridge [0607]: Ricoh Co Ltd Device [1180:e476] (rev 02)
> > 04:00.4 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd Device [1180:e832]
> > (rev 03) (prog-if 10)
> 
> I would guess that the DMAR can't distinguish between the different
> devices behind the Cardbus bridge.  Adding Dave Woodhouse.

Yeah, the DMAR looks at the source-id in the PCIe transactions, and it
sounds like those are all 04:00.0. But we've probably set up the DMAR to
allow the transactions from 04:00.4, and then it naturally faults when a
"different" device actually ends up doing the transaction.

If you make the pci_find_upstream_pcie_bridge() function do the
appropriate thing for this device, does it then work as expected?

Whether that's a _sane_ thing to do or not is possibly more of a Jesse
question...

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ