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) Subsystem: 106b:0030 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): kudzu-1.1.96-1 How reproducible: Always Steps to Reproduce: 1. use fc on ibook2, try to detect fw-controller with kudzu 2. 3. Actual Results: Kudzu does not see the controller Expected Results: Kudzu detects controller Additional info:
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 hardware, though.
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 /sys/bus/pci/devices/0002:20:0e.0/ both with, and without, the module loaded?
Seems to be identical as far as I can tell. Without a driver: pci:v0000106Bd00000030sv0000106Bsd00000030bc0Csc00i10 With driver: pci:v0000106Bd00000030sv0000106Bsd00000030bc0Csc00i10
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. class: FIREWIRE bus: PCI detached: 0 desc: "Apple Computer Inc. UniNorth/Pangea FireWire" vendorId: 106b deviceId: 0030 subVendorId: ffff subDeviceId: ffff pciType: 1 pcidom: 2 pcibus: 20 pcidev: e pcifn: 0 /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.