Bug 203734 - Firewire external HD confuses the kernel on Dell Precision M90
Firewire external HD confuses the kernel on Dell Precision M90
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
: Desktop
Depends On:
Blocks: 202880
  Show dependency treegraph
Reported: 2006-08-23 10:54 EDT by Suzanne Hillman
Modified: 2008-04-27 01:05 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-27 01:05:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Suzanne Hillman 2006-08-23 10:54:44 EDT
Description of problem:
Firewire external HD confuses the kernel on Dell Precision M90. (It worked fine
once if powered on before plugging it in, but has been giving that error
consistantly since)

The external drive is an iomega 120BG HDD, model DHD120-C, and is detected as
the following by the kernel the one time it worked:

"scsi1 : SBP-2 IEEE-1394
ieee1394: sbp2: Logged into SBP-2 device
   Vendor: HDS72251  Model: 2VLAT20      Rev:
   Type:   Direct-Access-RBC             ANSI SCSI revision"

It also mentions something about forcing the driver to serialize I/O
(serialize_io=1), and that serialize_io=0 might give better performance.

When it doesn't work, you get the following in /var/log/messages:
"kernel: ieee1394: Error parsing configrom for node 0-00:1023"

The firewire port is detected by lspci as:
03:01.0 Firewire (IEEE 1394): Ricoh Co Ltd Unknown device 0832

Version-Release number of selected component (if applicable):

How reproducible:
Nearly always. I'm not completely sure why it worked the once (other than that I
powered it on before plugging it into the firewire port, but that didn't make it
happy with subsequent tries).
Comment 1 Stefan Richter 2006-09-02 19:22:03 EDT
Things you could try:
 - Unload all 1394 drivers, plug disk in, load ohci1394.
 - After a failure, use the tool gscanbus (GUI) or 1394commander (nice CLI) to
reset the FireWire bus.
 - Check if there is a firmware update for the bridge chip used by Iomega
available anywhere.

More diagnostics would require the IEEE 1394 drivers to be recompiled with
Comment 2 David Lawrence 2006-09-05 11:17:02 EDT
Reassigning to correct owner, kernel-maint.
Comment 3 Kristian Høgsberg 2007-04-04 11:53:29 EDT
Suzanne, could you try the new stack we're shipping in rawhide and see if you
get better results with that?  Thanks.
Comment 4 Stefan Richter 2007-04-04 12:14:30 EDT
One much simpler thing I forgot to mention in comment #1:
(plug disk in and switch on)
# modprobe -r ohci1394
(wait a few seconds)
# modprobe ohci1394

If that helps it would of course be interesting to make it work without such a
procedure, but it can be tedious without direct access to the hardware. --- But
as Kristian said, maybe it works now with the rawhide kernel.
Comment 6 Stefan Richter 2008-03-04 11:29:36 EST
Has this bug been fixed by now?
Comment 7 Chuck Ebbert 2008-04-27 01:05:02 EDT
I'm pretty sure this is fixed but will close as insufficient_info.

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