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> 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): Severn How reproducible: Always 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 ... scsibus3: 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
Additional info from the IEEE 1394 for Linux Mailing Lists http://sourceforge.net/mailarchive/forum.php?thread_id=2584860&forum_id=5387 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: http://sourceforge.net/mailarchive/message.php?msg_id=4435487 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 ;-)
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.
Sounds like this needs attention in hotplug...
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?
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 noc_J
Um, if the module is stuck in 'initializing', that generally means the kernel oopsed. Check your logs.
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'?
Perhaps open that as a separate bug... this bug is about the drive being not recognized, as opposed to the module hanging.
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?
Ok, so, it wasn't the same problem, after all. More details in bug 103821.
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
2044.nptl was a step backward in firewire detection, had to remove my firewire cable to get past hardware detection
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.
*** Bug 104571 has been marked as a duplicate of this bug. ***
*** Bug 105824 has been marked as a duplicate of this bug. ***
still foo in kernel 2082.nptl
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.
Still foo in 2086.nptl, also did custom kernel to work around it, and found a kernelcfg bug - see 106286
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??
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: 2.4.22-1.2086.nptl 2.4.22-1.2082.nptl 2.4.22-1.2075.nptl 2.4.22-1.2061.nptl 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. Results: 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 Results: 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.
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!
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.
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
2088.nptl still only recognizes the first of my three FireWire devices. See my previous comment #21 for more detail.
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.
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 installed. Is this problem going to be resolved for the November 3rd final release????? See my previous comment #21 for more detail.
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 recognized. 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!
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.
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.
BitTorrent 3.3-1 hoses Firewire detection in kernel 2115.nptl I removed BitTorrent-3.3-1 and voila no more problems !!
*** Bug 108916 has been marked as a duplicate of this bug. ***
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 "NEW" to "CONFIRMED". 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.
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.
Confirmed fixed in FC2test1.
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?