Bug 587178 - firewire-ohci causes machine to become unusable when VT-d is enabled
Summary: firewire-ohci causes machine to become unusable when VT-d is enabled
Status: CLOSED DUPLICATE of bug 605888
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 13
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-29 09:24 UTC by Ben Skeggs
Modified: 2010-08-01 19:12 UTC (History)
13 users (show)

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


Attachments (Terms of Use)

Description Ben Skeggs 2010-04-29 09:24:25 UTC
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 14:49:49 UTC
Same problem on my Dell inspiron e6410.

Comment 2 Stefan Richter 2010-05-22 10:26:26 UTC
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 18:55:26 UTC
discussion of the bug at linux-pci and linux-kernel:
http://lkml.org/lkml/2010/5/22/69

Comment 4 Jared Smith 2010-07-27 00:39:32 UTC
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 07:50:14 UTC
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 19:55:25 UTC
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 18:55:37 UTC

*** 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.