Bug 587178 - firewire-ohci causes machine to become unusable when VT-d is enabled
firewire-ohci causes machine to become unusable when VT-d is enabled
Status: CLOSED DUPLICATE of bug 605888
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
13
All Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-29 05:24 EDT by Ben Skeggs
Modified: 2010-08-01 15:12 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-01 14:55:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ben Skeggs 2010-04-29 05:24:25 EDT
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
Comment 1 DM Smith 2010-05-14 10:49:49 EDT
Same problem on my Dell inspiron e6410.
Comment 2 Stefan Richter 2010-05-22 06:26:26 EDT
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?
Comment 3 Stefan Richter 2010-05-22 14:55:26 EDT
discussion of the bug at linux-pci and linux-kernel:
http://lkml.org/lkml/2010/5/22/69
Comment 4 Jared Smith 2010-07-26 20:39:32 EDT
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.
Comment 5 Stefan Richter 2010-07-27 03:50:14 EDT
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?
Comment 6 Pete 2010-07-29 15:55:25 EDT
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)
Comment 7 Chuck Ebbert 2010-08-01 14:55:37 EDT

*** This bug has been marked as a duplicate of bug 605888 ***

Note You need to log in before you can comment on or make changes to this bug.