Bug 174096

There were a few fixes related to recognition of FireWire devices going into
Linux 2.6.14 and 2.6.15. Try the latest release.

(I am not an FC user myself, therefore do not know which kernel you are actually
using...)

These bugs are being closed since a large number of updates have been released
after the FC5 test1 and test2 releases. Kindly update your system by running yum
update as root user or try out the third and final test version of FC5 being
released in a short while and verify if the bugs are still present on the system
.Reopen or file new bug reports as appropriate after confirming the presence of
this issue. Thanks

The problem still exists on FC5T3.

Please post the portion of /var/log/syslog (or what ever log file gets the
kernel messages) from a failing session.

As already stated above all I see in /var/log/messages is:

ieee1394: Error parsing configrom for node 0-00:1023

What is the kernel version number of FC5T3?

Could you build a kernel from source? If yes, configure it just like the stock
kernel but enable "excessive debugging output" in the IEEE 1394 section. Then
provide the log of a failing session. (Don't do this if you never built an own
kernel yet.)

Stefan, test3 was based on 2.6.16rc3-git1
Too bad IEEE1394_VERBOSEDEBUG isn't a module parameter eh? :)

Dave, you've got a point.

Bernd, here are things you could try before recompiling drivers:

1. Install gscanbus and post the information that it can gather.
2. Check which 1394 drivers are loaded ("lsmod"), unload them all with "modprobe
-r _modulename_", then reload them. Check the syslog messages.
3. Same as 2., but load ieee1394 by "modprobe ieee1394 disable_irm=1" before
loading the other 1394 drivers.

PS: Sometimes the "Error parsing configrom for node ..." is either for a
different node (e.g. hub), or sometimes the driver parses the ROM successfully
shortly after this error message. In this case, sbp2 should be loaded
automatically. However if userspace tools (udev, hotplug, hal or whatever) are
not updated for Linux 2.6.14's or later SCSI sysfs change, sbp2 is not loaded
automatically. (See the few other disk detection bugs at this site.) --- In
short, make sure the sbp2 kernel module is loaded to check whether it really is
an issue at driver level, not in userspace.

Yes, looks like a userspace issue. After issueing "modprobe sbp2" the drive is
found and I can disconnect and reconnect it without any problems. 

A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

(this is a mass-close to kernel bugs in NEEDINFO state)

As indicated previously there has been no update on the progress of this bug
therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue
still occurs for you and I will try to assist in its resolution. Thank you for
taking the time to report the initial bug.

If you believe that this bug was closed in error, please feel free to reopen
this bug.