Bug 432479 - firewire did not work properly
firewire did not work properly
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Jarod Wilson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-12 05:14 EST by G. Glock
Modified: 2008-03-27 13:21 EDT (History)
3 users (show)

See Also:
Fixed In Version: 2.6.24.3-50.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-27 13:21:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg from kernel 2.6.24.3-34 (35.74 KB, text/plain)
2008-03-21 21:43 EDT, Chad Paavola
no flags Details

  None (edit)
Description G. Glock 2008-02-12 05:14:20 EST
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
Comment 1 Stefan Richter 2008-03-04 10:56:16 EST
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.
Comment 2 Jarod Wilson 2008-03-04 11:08:21 EST
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/
Comment 3 Stefan Richter 2008-03-04 12:20:29 EST
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.
Comment 4 Jarod Wilson 2008-03-04 13:54:15 EST
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).
Comment 5 Chad Paavola 2008-03-21 21:43:14 EDT
Created attachment 298817 [details]
dmesg from kernel 2.6.24.3-34
Comment 6 Chad Paavola 2008-03-21 21:45:09 EDT
I'm having the same problem and submitted the dmesg output above.  Let me know
if I can provide any additional info.
Comment 7 Stefan Richter 2008-03-21 22:09:53 EDT
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?
Comment 8 Chad Paavola 2008-03-24 15:18:42 EDT
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.
Comment 9 Jarod Wilson 2008-03-24 15:27:47 EDT
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.
Comment 10 Stefan Richter 2008-03-24 16:53:41 EDT
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.
Comment 11 Chad Paavola 2008-03-24 19:24:37 EDT
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
Comment 12 G. Glock 2008-03-27 04:31:25 EDT
(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.
Comment 13 Stefan Richter 2008-03-27 07:15:14 EDT
> "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.
Comment 14 Jarod Wilson 2008-03-27 13:21:28 EDT
(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.

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