Bug 429950 - [firewire] unable to use disk (giving up on config rom)
[firewire] unable to use disk (giving up on config rom)
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: Jay Fenlason
Martin Jenner
Depends On:
  Show dependency treegraph
Reported: 2008-01-23 17:12 EST by Jarod Wilson
Modified: 2014-08-31 19:28 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 15:22:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Initial backport of upstream 'giving up on config rom' fixes (5.66 KB, patch)
2008-01-25 15:56 EST, Jarod Wilson
no flags Details | Diff

  None (edit)
Description Jarod Wilson 2008-01-23 17:12:23 EST
+++ This bug was initially created as a clone of Bug #429598 +++

Description of problem:
External firewire disk won't mount anymore

Version-Release number of selected component (if applicable):
uname -a
Linux sputnik.theory.org #1 SMP Fri Dec 7 15:49:36 EST 2007
x86_64 x86_64 x86_64 GNU/Linux

upgraded to latest packets as of 21 jan 2008

How reproducible:

Steps to Reproduce:
1. Plug the external disk into firewire
2. Switch it on
3. Won't mount anymore
Actual results:
External firewire disk won't mount anymore. FC6 used to work fine, same hardware.

dmesg sample:

Dec  3 03:03:02 sputnik kernel: ieee1394: Error parsing configrom for node 0-00:1023
Dec  3 03:03:10 sputnik kernel: scsi12 : SBP-2 IEEE-1394
Dec  3 03:03:11 sputnik kernel: ieee1394: sbp2: Logged into SBP-2 device
Dec  3 03:03:11 sputnik kernel: ieee1394: sbp2: Node 0-00:1023: Max speed [S400]
- Max payload [2048]

Expected results:
Should be seen and  mounted as used to in FC6.

Additional info:
The same unit mounted on usb works (it's a dual firewire/usb external disk)

-- Additional comment from jwilson@redhat.com on 2008-01-23 00:11 EST --
Those dmesg bits aren't valid for the Fedora 8 firewire stack. The ieee1394
stack isn't built or shipped, we ship the stack that prints 'firewire' instead,
and fw-sbp2 instead of just sbp2. Please get the appropriate firewire stack
running and we can certainly dig into this (might even already be fixed in the
latest koji kernels).

-- Additional comment from jwilson@redhat.com on 2008-01-23 00:13 EST --
Hrm, in re-reading, perhaps that was supposed to be an example of the working
case. To have a chance of getting things fixed, what I need is the non-working
case, as described in comment #1.

-- Additional comment from alf.tanner@gmail.com on 2008-01-23 08:40 EST --
Hi Jarod. No, it can't be an example of a working case since it's F8 as I
reported. With F8 firewire interface doesn't work.
You asked me to use the appropriate firewire stack. How do I do that in F8 in
order to report problems?

-- Additional comment from alf.tanner@gmail.com on 2008-01-23 09:37 EST --
Oops! Sorry, you're right, I've picked up the old messages file!
Here we are:

Jan 23 15:33:23 sputnik kernel: firewire_core: phy config: card 0, new
root=ffc1, gap_count=5
Jan 23 15:33:30 sputnik kernel: firewire_core: phy config: card 0, new
root=ffc1, gap_count=5
Jan 23 15:33:54 sputnik kernel: firewire_core: giving up on config rom for node
id ffc0

and that's all. fdisk -l cant' see any device, like automounter and gnome-mount.

-- Additional comment from jwilson@redhat.com on 2008-01-23 09:48 EST --
Yep, that's the bits I need. Basically, we're failing to read the configuration
rom on the drive, which means the firewire stack doesn't have a clue what sort
of capabilities the device has -- doesn't know if its a drive, a camera, or what
-- so we never set up the sbp2 layer for storage.

As it happens, I'm actually working on this very problem right now with the
upstream firewire maintainer, Stefan Richter (cc'ing). I can reproduce this on
my laptop, and really want to use some firewire drives with it, so you can be
sure I plan to get it working reliably... ;)

-- Additional comment from alf.tanner@gmail.com on 2008-01-23 10:26 EST --
Excellent, thanks a lot.

So is this a kernel fault only or udev is involved as well?

-- Additional comment from stefan-r-rhbz@s5r6.in-berlin.de on 2008-01-23 10:36
EST --
It's purely a fault in the kernel drivers.  Once we got them fixed, udev and
friends will do the right thing.

-- Additional comment from jwilson@redhat.com on 2008-01-23 16:31 EST --
I've got a patch based on some of Stefan's work and some review comments that is
working quite well now on multiple system and drive combinations that were
previously hitting the 'giving up on config rom' problem, which I've added to
rawhide, and after a touch more testing, will get it into F8 and F7.
Comment 1 Jarod Wilson 2008-01-23 17:14:02 EST
Would be a very good thing to get into RHEL5.2, enables a LOT more firewire
storage devices to actually work with our firewire stack.
Comment 3 Jay Fenlason 2008-08-14 13:21:47 EDT
It looks to me like this patch is included in the 5.3 patch I just posted.  Can you please confirm?
Comment 4 Jarod Wilson 2008-08-18 11:27:38 EDT
Yep, looks like these are covered by that patch. Brief testing results look good too.
Comment 6 Don Zickus 2008-09-10 16:13:04 EDT
in kernel-2.6.18-110.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 9 errata-xmlrpc 2009-01-20 15:22:43 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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