DMAR:[fault reason 02] Present bit in context entry is clear (firewire-ohci)

[Stefan Richter]

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)

Thanks for any hint,
--
Stefan Richter
-=====-==-=- -=-= =-==-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Matthew Wilcox]

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.

--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."

[David Woodhouse]

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.W...@intel.com Intel Corporation

[Jesse Barnes]

Well, if cardbus bridges tend to behave this way in general it would
make sense to simply use the cardbus bride id everywhere, rather than
the specific functions of the device. Cc'ing Dominik.

Jesse

[Stefan Richter]

>>> On Sat, May 22, 2010 at 12:26:15PM +0200, Stefan Richter wrote:

>>>> https://bugzilla.redhat.com/show_bug.cgi?id=587178

Thanks to those who responded. Alas I cannot follow up on this myself
with tests since I don't have affected hardware.
--
Stefan Richter
-=====-==-=- -=-= ====-
http://arcgraph.de/sr/

[Tomáš Janoušek]

Hello guys,

On Sat, May 22, 2010 at 12:09:05PM -0700, Jesse Barnes wrote:
> On Sat, 22 May 2010 19:40:43 +0100
> David Woodhouse <dw...@infradead.org> wrote:

> > [...]

> > 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...
>
> Well, if cardbus bridges tend to behave this way in general it would
> make sense to simply use the cardbus bride id everywhere, rather than
> the specific functions of the device. Cc'ing Dominik.

Any news on this one? It is still an issue with current kernel on current
hardware (like my ThinkPad T420). :-(

Regards,
--
Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/

[Clemens Ladisch]

Tomáš Janoušek wrote:
> On Sat, May 22, 2010 at 12:09:05PM -0700, Jesse Barnes wrote:
>> On Sat, 22 May 2010 19:40:43 +0100
>> David Woodhouse <dw...@infradead.org> wrote:
>>> [...]
>>> 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...
>>
>> Well, if cardbus bridges tend to behave this way in general it would
>> make sense to simply use the cardbus bride id everywhere, rather than
>> the specific functions of the device. Cc'ing Dominik.
>
> Any news on this one?

Apparently not.

Try the patch in <https://bugzilla.redhat.com/show_bug.cgi?id=605888>
that is intended to work around the bug in your Ricoh chip. Alternatively,
disable VT-d or FireWire in the BIOS, or add the kernel parameter
"intel_iommu=off".


Regards,
Clemens