Red Hat Bugzilla – Bug 140753
kudzu does not see iBook2 internal firewire controller
Last modified: 2014-03-16 22:50:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041114 Firefox/1.0
Description of problem:
The internal firewire controller of my ibook2 is not seen by kudzu (and consequently by /sbin/kmodule). lspci -vvv of the device:
0002:20:0e.0 Class 0c00: 106b:0030 (prog-if 10)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 16 (3000ns min, 6000ns max), Cache Line Size 08
Interrupt: pin A routed to IRQ 40
Region 0: Memory at 00000000f5000000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <available only to root>
It works with the standard ohci1394 driver.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. use fc on ibook2, try to detect fw-controller with kudzu
Actual Results: Kudzu does not see the controller
Expected Results: Kudzu detects controller
Is it still class '0c00' when the module is not loaded?
Yes, but it looks a bit strange (/sbin/lspci -vvn):
0002:20:0e.0 Class 0c00: 106b:0030 (rev ff) (prog-if ff)
!!! Unknown header type 7f
It's the (prog-if ff). ohci1394 only matches cards with prog-if 0x10.
So this controller needs an exception rule?
Hm, maybe. I'd wonder if it would start generating false matches on other
Sounds like a power management thing. While devices aren't used, the
ibook can actually shut them down completely, and you end up getting
0xff back from all configuration reads. That caused problems when the
device and vendor IDs were all 0xFFFF, preventing the devices from
being detected properly -- I think we ended up caching the idents. We
should probably be caching the revision and prog-if too.
Does this still happen with rawhide kudzu? The code has been changed to use the
modules.alias directly exported by the driver.
No luck so far.
kernel is 2.6.13-1.1582_FC5
kudzu is 1.2.9-1
I have a line stating "alias ieee1394-controller ohci1394" in /etc/modprobe.conf
What's the modalias in
both with, and without, the module loaded?
Seems to be identical as far as I can tell.
Without a driver:
Odd. Running 'modprobe -n -v
"pci:v0000106Bd00000030sv0000106Bsd00000030bc0Csc00i10"' correctly shows that it
will load the ohci1394 driver.
kudzu -p -b pci doesn't list the driver right?
It does, as a matter of fact.
desc: "Apple Computer Inc. UniNorth/Pangea FireWire"
/sbin/kmodule, on the other hand, does not. Do I have to nuke a file somewhere?
Actually, according to that, it doesn't - there's no 'driver:' line.
This has moved out of kudzu's realm in FC5 and later - udev is solely
responsible for loading modules.