Bug 101227 - firewire hdd is recognized (sbp2 loads) but does not work (no blk device)
Summary: firewire hdd is recognized (sbp2 loads) but does not work (no blk device)
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Matthew Galgoci
QA Contact: Brian Brock
: 104571 105824 108916 (view as bug list)
Depends On:
Blocks: CambridgeTarget 106926
TreeView+ depends on / blocked
Reported: 2003-07-30 10:16 UTC by G. Schneider
Modified: 2007-11-30 22:10 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-02-16 22:32:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description G. Schneider 2003-07-30 10:16:40 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

Description of problem:
After plugging in a firewire hdd, the module sbp2 correctly loads:

output of 
cat /proc/scsi/sbp2_0/2
Host scsi2             : SBP-2 IEEE-1394 (ohci1394)
Driver version         : $Rev: 953 $ Ben Collins <bcollins@debian.org>

Module options         :
  max_speed            : S800
  max_sectors          : 255
  serialize_io         : no
  exclusive_login      : yes

Attached devices       : none

The last line seems suspicious?

but the hdd is not functioning (no device /dev/sd[abc]1 etc.) 
hdd does not appear on scsi bus (compare expected results)

Hardware: Sony Laptop GRX-700 + firewire hdd

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

How reproducible:

Steps to Reproduce:
1.plug in firewire hdd
2.for example check failure with cdrecord -scanbus


Actual Results:  
Firewire HDD does not appear as scsi device
cannot find device /dec/sd[abc]1 etc.
cannot mount

Expected Results:  cdrecord -scanbus
        3,0,0   300) 'WDC WD12' '00JB-00CRA1     ' '    ' Disk
can be mounted and used

(works on RH9 + kernel patched with ACPI and other Linux distros (Suse 8.2))

Additional info:

possibly related to Bug#100545
kudzu will hang when the firewire hdd is plugged in

Comment 1 G. Schneider 2003-07-30 11:53:57 UTC
Additional info from the IEEE 1394 for Linux Mailing Lists


 The difference between the 2.4.20 and 2.4.21 kernels is that old
 versions of sbp2 added all SBP-2 devices (that were found when
 the sbp2 driver was loaded) before the SCSI driver run the
 initial bus scan. With the new sbp2 driver, the devices ar added
 a bit later, which requires a manual bus rescan to activate the
 devices at the SCSI layer.
 A technical explanation why this was changed is here:

 I haven't tried if a manual rescan helps but I will and add the info tomorrow.
 Anyways, this looks exactly like my problem.

 Hope this will help you guys fix this for beta2 ;-) 

Comment 2 G. Schneider 2003-07-31 08:02:57 UTC
after executing (as root) the script rescan-scsi-bus.sh
as found at http://www.linux1394.org/sbp2.html

the firewire hdd is recognized and functioning. You will find enough info on
that page to explain the problem in this bug and other firewire related bugs.

Comment 3 Michael K. Johnson 2003-08-08 20:31:00 UTC
Sounds like this needs attention in hotplug...

Comment 4 Bill Nottingham 2003-08-08 21:25:46 UTC
OK, so, becuase they couldn't fix a refcounting issue to avoid an oops on manual
unload of a different module, the change was made to make the storage adapter
driver require manual intervention, unlike *every single other storage adapter*
in the tree? WTF?

Am I misreading this here?

Comment 5 raxet 2003-08-16 05:18:30 UTC
Here is what I got after enabling my onboard 1394 with Severn (from sys log):

Loading sb2p.o module
SCSI0: SCSI emulation for IEEE-1394 SBP-2 Devices
blk:queue C1993014, I/O limit 4095 mb mask 0xffffffff
IEEE1394: sbp2: Logged into SBP-2 device '

Hangs the system

If I disable in bios, sbp2.o is fine


Comment 7 Bill Nottingham 2003-09-03 18:44:33 UTC
Um, if the module is stuck in 'initializing', that generally means the kernel
oopsed. Check your logs.

Comment 8 Alexandre Oliva 2003-09-03 23:05:10 UTC
FWIW, with kernel-2.4.22-20.1.2024.2.36.nptl: kudzu hangs if the disk drive is
plugged in at the time it runs.  If I plug it in later, the sbp2 module is
loaded properly, but remains in `initializing' state forever.  No logs anywhere.
 If I arrange for sbp2 to be loaded by initrd )mkinitrd -f --with=scsi_mod
--with=sbp2 --with=sd_mod --with=usb-uhci --with=usb-storage), boot hangs at the
time the sbp2 module would be loaded, as long as the disk is plugged in.

/me considers this a serious regression from Shrike.  Any chance we could
consider this is a `must fix'?

Comment 9 Bill Nottingham 2003-09-03 23:10:17 UTC
Perhaps open that as a separate bug... this bug is about the drive being not
recognized, as opposed to the module hanging.

Comment 10 Alexandre Oliva 2003-09-04 00:23:53 UTC
Err...  I think it's actually the same bug (which is why I added to it, instead
of filing separately).  The symptoms I get are exactly the same: sbp2 loads (but
doesn't complete initializing), but the drive remains inaccessible as /dev/sda.

FWIW, in the Severn install disk, /dev/sda is accessible, but it maps to the
internal (IDE) CD-ROM.  So maybe this is a different bug, after all?

Comment 11 Alexandre Oliva 2003-09-05 13:10:53 UTC
Ok, so, it wasn't the same problem, after all.  More details in bug 103821.

Comment 12 raxet 2003-09-13 05:00:31 UTC
My logs don't show jack anything once the below "Logged into SPB-2 device"
appears. If there is kernel oops, I can't see it in any log. Again nothing can
be loaded after that point.

Sep  8 02:12:39 maxer kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
Sep  8 02:12:39 maxer kernel: ieee1394: sbp2: Logged into SBP-2 device

Comment 13 raxet 2003-09-16 00:39:47 UTC
2044.nptl was a step backward in firewire detection, had to remove my firewire
cable to get past hardware detection

Comment 14 raxet 2003-09-27 17:38:28 UTC
Although sbp2.o loads in the kernel just fine in 2.4.22-1.2061.nptl, running
rescan-scsi-bus.sh doesn't detect jack.

sh ./rescan-scsi-bus.sh
Host adapter ? (*) found.
0 new device(s) found.
0 device(s) removed.

Not to mention the fact that the Adaptec firewire card (AFW-4300 FCONN) that was
detectable in RH 9 is now hanging kernel boot when attached to the BUSLink
48x12x48 external drive. I really have no interest in seeing support dropped for
firewire in the new release.

Comment 15 Dave Jones 2003-09-29 01:33:08 UTC
*** Bug 104571 has been marked as a duplicate of this bug. ***

Comment 16 Dave Jones 2003-09-29 01:43:53 UTC
*** Bug 105824 has been marked as a duplicate of this bug. ***

Comment 17 raxet 2003-10-01 22:23:33 UTC
still foo in kernel 2082.nptl

Comment 18 Dave Jones 2003-10-02 14:27:22 UTC
There was a hack added yesterday which may solve this. It's not pretty, but if
it works, we'll likely go with that.  I'm just building & pushing out 2084.

Comment 19 raxet 2003-10-04 22:14:51 UTC
Still foo in 2086.nptl, also did custom kernel to work around it, and found a
kernelcfg bug - see 106286

Comment 20 raxet 2003-10-05 20:36:32 UTC
Still foo in 2087.nptl and I tried a custom kernel Would like to know what in
2084 was the work around that wasn't pretty but worked??

Comment 21 Jeff McClure 2003-10-06 09:51:09 UTC
I've been experiencing partial success with FireWire drives with Fedora Test2
release, so I thought I'd post my findings in case they are useful.  

First I'll note that FireWire works 100% fine under RedHat 9 with the standard
RedHat 9 kernels (all three of my firewire devices work great).  It's only under
Fedora that FireWire is broken.  Also, I've tried the Fedora kernels under
RedHat 9, and that doesn't work for FireWire, and a number of other things
(oddly enough including emacs).

On to my results with Fedora Test2.  I've tried all of the following kernels,
and they all behave the exact same:


Hardware:  Dell Inspiron 5000e laptop, no built-in FireWire, no built-in networking.

HP dvd200e.
     Connected via FireWire, directly connected to laptop (not daisy-chained)

External FireWire Drive #1.
     ADS Technologies housing capable of FireWire 400 and USB 2 
     250G Western Digital Drive installed in housing. 
     Connected via FireWire, directly connected to laptop (not daisy-chained)

External FireWire Drive #2 
     Unknown FireWire drive enclosure, capable of FireWire and USB (not sure
which USB)
     This enclosure is older than the ADS Technologies enclosure.
     120G Western Digital Drive within housing.
     Connected via FireWire, directly connected to laptop 
     (not daisy-chained)

3Com PCMCIA networking card.

FireWire PCMCIA card with 3 FireWire 400 ports.  
     Not branded, bought at Frye's, the lable is red.
     printed on the lable is says that the following systems are 
     supported: Windows 9x/ME/2000/XP, Mac 8.6 and above, Linux OS.

In all cases the PCMCIA networking card works perfectly, which demonstrates that
at some level PCMCIA services are working just fine.

Scenario 1
Boot with FireWire card installed, and all FireWire devices connected. 

  No FireWire drives are automatically detected
  rescan-scsi-bus.sh hangs, and never recognizes any devices.

Scenario 2
1) Boot with FireWire card not plugged into PCMCIA slot.
2) Once boot is complete insert FireWire card into PCMCIA slot with all three
FireWire devices plugged into card (not daisy-chained).
3) Run rescan-scsi-bus.sh

    External FireWire drive #1 is recognized (the newest of my FireWire
devices), and is mountable.  The drive works perfectly with good performance.

Note: If at any point in Scenario 1 or Scenario 2 the FireWire card is ejected
(even with no mounted filesystems), the system stops responding to keyboard
input (mouse continues to work fine), and must be rebooted.

Comment 22 raxet 2003-10-07 03:08:09 UTC
After looking at this a little more and referring back to the recent notes from
Jeff, I can unplug the firewire with the latest 2.6 test kernel and after
booting to gnome desktop, plug my BUSLink 48x12x48 drive and guess what?
Xcdroast loaded and voila I have access to the drive?? I can even burn CDRW's!! 

So what gives on kernel boot? Beats me! 

Comment 23 Jeff McClure 2003-10-07 06:04:19 UTC
I did some additional testing and learned that any one of my FireWire devices
can be detected, but only one at a time.  I still wait for the system to boot
and then install the PCMCIA FireWire card, and then run the rescan-scsi-bus.sh
script.  It seems that the ports on the FireWire card are search in a specific
order (or there is some sort of priority resolution), if a device is found on
port 1, it is configured.  If no device is found on port 1, it checks port 2,
then it checks port 3.  

Comment 24 raxet 2003-10-12 03:33:37 UTC
2088.nptl now allows for plugging of firewire CDRW after kernel boot AND... sh
./rescan-scsi-bus NOW finds the BUSLink drive:
sh ./rescan-scsi-bus.sh
Host adapter 0 (sbp2_0) found.
Scanning for device 0 0 0 0 ...
NEW: Host: scsi0 Channel: 00 Id: 00 Lun: 00
      Vendor: LITE-ON  Model: LTR-48125W       Rev: VS06
      Type:   CD-ROM                           ANSI SCSI revision: 02
1 new device(s) found.

We still have the issue where leaving the device plugged at kernel boot where it
will hang the kernel

Comment 25 Jeff McClure 2003-10-12 16:55:22 UTC
2088.nptl still only recognizes the first of my three FireWire devices.  See my
 previous comment #21 for more detail.

Comment 26 Jeff McClure 2003-10-16 16:36:41 UTC
2093.nptl still only recognizes the first of my three FireWire devices. 
However, it does allow me to leave the FireWire PCMCIA card installed from the
start of the boot process.  Once the system is booted I run rescan-scsi-bus.sh
to configure the  devices.

Also, shutdown hangs and never completes whenever I have my PCMCIA FireWire card
installed.  This has happend with all previous kernels as well.

See my previous comment #21 for more detail.

Comment 27 Jeff McClure 2003-10-17 22:19:10 UTC
2096.nptl still only recognizes the first of my three FireWire devices. 

My FireWire PCMCIA card must be unplugged at boot time, and then inserted once
boot completes, and then run rescan-scsi-bus.sh to recognize FireWire devices. 
If the card is installed during boot then FireWire devices will never be recognized.

Shutdown hangs and never completes whenever I have my PCMCIA FireWire card

Is this problem going to be resolved for the November 3rd final release?????

See my previous comment #21 for more detail.

Comment 28 Jeff McClure 2003-10-29 02:20:04 UTC
Everything seems to be working fine with 2.4.22-1.2110.nptl.  Using
rescan-scsi-bus.sh all of my FireWire devices on the FireWire daisy-chain are

I haven't tested all the kernels up to this version, so I don't know exactly
which version rectified the problem.

On my laptop, I can boot with my PCMCIA card installed, however I still need to
use the rescan-scsi-bus.sh.

On my desktop I need to run:
   modprobe -r sbp2; modprobe sbp2
and then run the rescan-scsi-bus.sh script.

Great work kernel team!!!!!  Thanks alot!

Comment 29 raxet 2003-11-02 15:24:30 UTC
Well folks 2115 worked since rawhide push but...

2.4.22-1.2115.nptl.i686 broke today! Can't leave CDRW hot plugged on
boot, I can use rescan-scsi-bus after booting then plugging.
Can't figure it out. Nothing has changed on my system at all. No
packages were changed since the last push to rawhide.

Comment 30 raxet 2003-11-02 19:48:03 UTC
With 2105.nptl all the way through and including 2115.nptl installed a
few days back I could leave my BUSLink Firewire CDRW drive plugged.
Now all of a sudden the boot process hangs just as before. If I leave
my drive unplugged and wait till after that point in the kernel where
ohci loads, then I can successfully use the bourne script
rescan-scsi-bus to successfully detect the drive and use it... go
figure. The only addition I have added recently was BitTorrent-3.3-1.

Comment 31 raxet 2003-11-02 20:07:47 UTC
BitTorrent 3.3-1 hoses Firewire detection in kernel 2115.nptl

I removed BitTorrent-3.3-1 and voila no more problems !!

Comment 32 Dave Jones 2003-11-10 17:07:31 UTC
*** Bug 108916 has been marked as a duplicate of this bug. ***

Comment 33 Trevor Harmon 2003-12-19 01:02:32 UTC
Just wanted to mention that (like many others here) I have confirmed
this bug on Fedora Core 1, so perhaps its status needs to change from

I've been mounting an external FireWire drive since Red Hat Linux 7.3,
8.0, and 9, and all of them create a /dev/sda1 for mounting as soon as
I plug in the cable. After upgrading to Fedora Core 1, however,
plugging in the cable loads the modules, but /dev/sda1 cannot be
mounted. I have to run rescan-scsi-bus
(http://www.ic.unicamp.br/~oliva/snapshots/FC1-firewire/) in order to
make /dev/sda1 mountable.

I'm happy there's an easy workaround, but it's less convenient than
ever, so I hope it can be fixed in the next version of Fedora.

Comment 34 Alexandre Oliva 2003-12-19 16:04:15 UTC
The good news is that kernel 2.6 doesn't require rescan-scsi-bus;
hotplugging just works.  The bad news is that the problem in 2.4 is
deemed unfixable by the maintainer of the sbp2 module.

Comment 35 Alexandre Oliva 2004-02-16 22:32:24 UTC
Confirmed fixed in FC2test1.

Comment 36 David Monniaux 2004-05-03 19:36:24 UTC
Same with me on my laptop with a FireWire CD-Rom:
   modprobe -r sbp2; modprobe sbp2
and then run the rescan-scsi-bus.sh script.

Could this be put in the default init sequence?

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