Description of problem: When VT-d is enabled in the BIOS on a Dell M4500, the system hangs once the firewire-ohci module has been loaded. Version-Release number of selected component (if applicable): All F13 kernels tested (up to kernel-2.6.33.3-73) and upstream release 2.6.34-rc5. How reproducible: Every time. Steps to Reproduce: 1. Enable VT-d in BIOS on a machine with a device handled by firewire-ohci 2. Boot the kernel Actual results: Continuous DMAR messages flooding the VT, resulting in the inability to boot. Expected results: The kernel boots normally, and doesn't cause a hang. Additional info: Captured a snipped of the dmesg output over netconsole after loading the firewire-ohci module manually: netconsole: network logging started 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
Same problem on my Dell inspiron e6410.
According to a web search, the devices are: 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 believe the DMA that happens at this moment is from the device 04:00.4 to main memory into a consistent buffer (self ID reception). Perhaps the kernel missed to set up the CardBus bridge correctly?
discussion of the bug at linux-pci and linux-kernel: http://lkml.org/lkml/2010/5/22/69
I'm seeing this same thing... Turning on VT-d support on my Lenovo T510 keeps anaconda from being able to install, and turning VT-d support on *after* the installation fills /var/log/messages with DRHD and DMAR messages just like the ones above. I'm happy to help test changes if people would like me to be a guinea pig.
Jared, what machine do you have and what does "lspci -nn" say about the FireWire device and about the device whose ID turns up in the kernel log messages?
I'm having the same trouble on my Lenovo T410 (2522-AL3). Here are the 0d:00.* entries from lspci -nn: 0d:00.0 SD Host controller [0805]: Ricoh Co Ltd Device [1180:e822] (rev 01) 0d:00.1 System peripheral [0880]: Ricoh Co Ltd Device [1180:e230] (rev 01) 0d:00.3 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd Device [1180:e832] (rev 01)
*** This bug has been marked as a duplicate of bug 605888 ***