From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.10) Gecko/20071213 Fedora/2.0.0.10-3.fc8 Firefox/2.0.0.10 Description of problem: Hi all, I have a similar problem to that described in BUG-ID 429598 by 'Nicola', but my problem is vice-versa. My external FW-components are working properly until kernel-2.6.23.9-85 (which is actually the one I'm still using at the moment). Since then I tried any official kernel-release (including the one just arrived - 2.6.23.15-137), but the messages I get after attaching an external FW-Device is the same that Nicola described using 2.6.23.9-85 (...giving up on config rom...). In the latest kernel-changelog I found a hint about bugfixes on the FW-related stuff, but unfortunately still nothing changed. My HW: - Gigabyte GA-X38-DQ6 - onboard OHCI TI TSB43AA23 - IEEE1394b-PCI-Card with TI TSB82AA4 - ext. FW-Harddrive - IIDC1394-Camera I suspect it's an issue with the new fw-stack. I further suspect that since 2.6.23.14-107 the stuff related to the old FW-stack has been removed, hasn't it? How to get around this issue? Do I have to change some permissions or is it really a bug? Version-Release number of selected component (if applicable): kernel-2.6.23.15-137.fc8 How reproducible: Always Steps to Reproduce: 1.plug in an external FW-Device 2.wait, and see that nothing happens 3.after a while 'dmesg' shows: "giving up on config rom..." Actual Results: see Description Expected Results: Working devices as before (with kernel-2.6.23.9-85...) Additional info: If you need more information, please let me know
Jarod, is there anything interesting in the delta from 2.6.23.9-85 to 2.6.23.15-137? Since somebody else had the "giving up on config rom" issue already in 2.6.23.9-85, I suppose the issue was just latent for this setup here and brought to the surface by some more or less related change. A kernel with patch "firewire: replace static ROM cache by allocated cache" would be good to try here, although I have no idea whether the theoretical condition addressed by that patch can realistically happen. Also, we still need to implement better dmesg output for the "giving up" event. I started to work on it but got distracted.
The fix for the bulk of 'giving up on config rom' problems went into 2.6.23.14-130, so yeah, 2.6.23.15-137 could be interesting to try out. The 'replace static ROM cache' bits went into 2.6.24.3-17 last night, which can be pulled straight out of the build system: http://koji.fedoraproject.org/packages/kernel/2.6.24.3/17.fc8/
Re comment #2: In this case, 2.6.23.9-85 = good, 2.6.23.15-137 = bad. Re initial comment: > I suspect it's an issue with the new fw-stack. > I further suspect that since 2.6.23.14-107 the stuff > related to the old FW-stack has been removed, hasn't it? The new stack has been in use since F7.
Whoops, didn't read carefully enough, assumed the problem was with the older kernel... Hrm. That's odd. I've not seen any regressions myself, only improvements... Can we get a full dmesg dump when booting off the newer kernel? (preferably w/2.6.24.3-17.fc8).
Created attachment 298817 [details] dmesg from kernel 2.6.24.3-34
I'm having the same problem and submitted the dmesg output above. Let me know if I can provide any additional info.
Chad, what if you # modprobe -r firewire-ohci # modprobe firewire-ohci while you leave whatever external FireWire device you have plugged in? And is your issue really the same as G.'s in so far as 2.6.23.9-85 or so still worked for you?
Stefan, when I do as you suggest, I get the following in dmesg: ACPI: PCI interrupt for device 0000:07:03.0 disabled firewire_ohci: Removed fw-ohci device. ACPI: PCI Interrupt 0000:07:03.0[A] -> GSI 19 (level, low) -> IRQ 19 firewire_ohci: Added fw-ohci device 0000:07:03.0, OHCI version 1.10 firewire_core: created device fw0: GUID 0090270001f9034a, S400 firewire_core: phy config: card 0, new root=ffc1, gap_count=5 firewire_core: giving up on config rom for node id ffc0 I don't know if it would work with and earlier kernel, as I've only tried it with 2.6.24.3-12 and 2.6.24.3-34. I'll try 2.6.23.9-85 and let you know how it works.
I'd also be curious to know how 2.6.24.3-50.fc8 fares, as it should have all but the very latest firewire bits in it, and improved things considerably for some people vs. 2.6.24.3-34.fc8.
Chad, _if_ 2.6.24.3-50.fc8 (or anything later) works for you, forget my question about 2.6.23.something. Mr. Glock, please try 2.6.24.3-50.fc8 as well. If this still fails, try # echo -1 > /sys/module/firewire_ohci/parameters/debug (a new parameter, hopefully already available in -50.fc8), then plug the device in, and post the resulting contents of dmesg. Thanks.
Success! 2.6.24.3-50 works for me, both my firewire drives mount correctly. Thanks much. From dmesg: firewire_core: created device fw0: GUID 0090270001f9034a, S400 firewire_core: created device fw1: GUID 0010b9f701148fdd, S400 firewire_core: created device fw2: GUID 0080cf0245001543, S400 firewire_core: phy config: card 0, new root=ffc1, gap_count=7 scsi8 : SBP-2 IEEE-1394 scsi9 : SBP-2 IEEE-1394 firewire_sbp2: Workarounds for fw2.0: 0x2 (firmware_revision 0x000234, model_id 0x000000) firewire_sbp2: fw1.1: logged in to LUN 0000 (0 retries) scsi 8:0:0:0: Direct-Access Maxtor OneTouch 0200 PQ: 0 ANSI: 4 sd 8:0:0:0: [sdb] 320171008 512-byte hardware sectors (163928 MB) sd 8:0:0:0: [sdb] Write Protect is off sd 8:0:0:0: [sdb] Mode Sense: 27 00 00 00 sd 8:0:0:0: [sdb] Cache data unavailable sd 8:0:0:0: [sdb] Assuming drive cache: write through sd 8:0:0:0: [sdb] 320171008 512-byte hardware sectors (163928 MB) sd 8:0:0:0: [sdb] Write Protect is off sd 8:0:0:0: [sdb] Mode Sense: 27 00 00 00 sd 8:0:0:0: [sdb] Cache data unavailable sd 8:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sd 8:0:0:0: [sdb] Attached SCSI disk sd 8:0:0:0: Attached scsi generic sg2 type 0 firewire_sbp2: fw2.0: logged in to LUN 0000 (0 retries) scsi scan: INQUIRY result too short (5), using 36 scsi 9:0:0:0: Direct-Access WDC WD60 0BB-00BSA0 12.0 PQ: 0 ANSI: 0 sd 9:0:0:0: [sdc] 117231408 512-byte hardware sectors (60022 MB) sd 9:0:0:0: [sdc] Write Protect is off sd 9:0:0:0: [sdc] Mode Sense: 86 08 00 02 sd 9:0:0:0: [sdc] Got wrong page sd 9:0:0:0: [sdc] Assuming drive cache: write through sd 9:0:0:0: [sdc] 117231408 512-byte hardware sectors (60022 MB) sd 9:0:0:0: [sdc] Write Protect is off sd 9:0:0:0: [sdc] Mode Sense: 86 08 00 02 sd 9:0:0:0: [sdc] Got wrong page sd 9:0:0:0: [sdc] Assuming drive cache: write through sdc: sdc1 sd 9:0:0:0: [sdc] Attached SCSI disk sd 9:0:0:0: Attached scsi generic sg3 type 0 device-mapper: multipath: version 1.0.5 loaded loop: module loaded
(In reply to comment #10) > Chad, _if_ 2.6.24.3-50.fc8 (or anything later) works for you, forget my question > about 2.6.23.something. > > Mr. Glock, please try 2.6.24.3-50.fc8 as well. If this still fails, try > # echo -1 > /sys/module/firewire_ohci/parameters/debug > (a new parameter, hopefully already available in -50.fc8), then plug the device > in, and post the resulting contents of dmesg. > > Thanks. Hi, apologies for the delay, but I was very busy in the last few weeks. Nevertheless I found out that the problem was not that fw denied working since the mentioned kernel version, but because I had installed an available ieee1394-kmdl package from 'atrpms' which used the the old fw-stuff. Because this module was not directly available for the 2.6.23.15-137 kernel the mentioned problems occurred. After removing this package fw did also deny working for the 2.6.23.9-85 kernel. Fortunately you found out some problems (also with the support of Chad - thank's for that...), so with the 2.6.24.3-50 release the main problem has been resolved (detecting and activating an attached fw-hd), but one message still seems very strange: "firewire_core: BM lock failed, making local node (ffc0) root." which also occurred with the problem. Nevertheless it seems working fine at the moment. Here is an excerpt of the 'dmesg'-output after attaching the ext. HD: firewire_core: BM lock failed, making local node (ffc0) root. firewire_core: phy config: card 1, new root=ffc0, gap_count=5 firewire_core: created device fw2: GUID 0050770e00001f8f, S400 scsi10 : SBP-2 IEEE-1394 firewire_sbp2: fw2.0: logged in to LUN 0000 (0 retries) scsi 10:0:0:0: Direct-Access-RBC SAMSUNG SP1634N PQ: 0 ANSI: 4 sd 10:0:0:0: [sdc] 312581808 512-byte hardware sectors (160042 MB) sd 10:0:0:0: [sdc] Write Protect is off sd 10:0:0:0: [sdc] Mode Sense: 11 00 00 00 sd 10:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 10:0:0:0: [sdc] 312581808 512-byte hardware sectors (160042 MB) sd 10:0:0:0: [sdc] Write Protect is off sd 10:0:0:0: [sdc] Mode Sense: 11 00 00 00 sd 10:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sd 10:0:0:0: [sdc] Attached SCSI disk sd 10:0:0:0: Attached scsi generic sg4 type 14 SELinux: initialized (dev sdc1, type vfat), uses genfs_contexts Also the IIDC1394 camera seems to be detected correctly after connecting. Unfortunately I have some problems using the camera from within an application, but I suspect, that this is a problem with 'libdc1394' (or, better yet, the source of this library, because it's also from 'atrpms' - I will find out that shortly...). A further advantage of the 2.6.24.3-50 kernel is that the strange "pnpacpi: exceeded the max number of mem resources. Max:12 Found:12" message (see 'Bugzilla Bug 436589') while booting has gone. Thank's for your support so far. And I think, if the strange 'BM lock' message mentioned above is not a serious problem, the problem is solved for the moment. If you still need the whole 'dmesg' output (maybe for solving also this little problem) please let me know.
> "firewire_core: BM lock failed, making local node (ffc0) root." No problem. Maybe we should remove the message from the driver. > Also the IIDC1394 camera seems to be detected correctly after > connecting. Unfortunately I have some problems using the camera > from within an application, but I suspect, that this is a problem > with 'libdc1394' (or, better yet, the source of this library, because > it's also from 'atrpms' - I will find out that shortly...). To use the stock Fedora kernel, you need stock Fedora's libdc1394 RPM. Vice versa, to use the atrpms' alternative driver RPM, you need atrpms' libdc1394 RPM. In a distant, brighter future, there will be a libdc1394 (and libraw1394) which automagically works with any of the kernel drivers. But they don't do yet.
(In reply to comment #13) > > Also the IIDC1394 camera seems to be detected correctly after > > connecting. Unfortunately I have some problems using the camera > > from within an application, but I suspect, that this is a problem > > with 'libdc1394' (or, better yet, the source of this library, because > > it's also from 'atrpms' - I will find out that shortly...). > > To use the stock Fedora kernel, you need stock Fedora's libdc1394 RPM. Vice > versa, to use the atrpms' alternative driver RPM, you need atrpms' libdc1394 > RPM. In a distant, brighter future, there will be a libdc1394 (and libraw1394) > which automagically works with any of the kernel drivers. But they don't do yet. Speaking of libraw1394, atrpms also provides an old-stack version of that as well, so you may well need to back that out too.