From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: FireWire does not appear to be working in the 2.6.14 FC4 kernels. My IOMEGA external HDD is not recognised and mounted, despite working flawlessly in the 2.6.13 kernels. Version-Release number of selected component (if applicable): kernel-2.6.14-1.1644_FC4 How reproducible: Always Steps to Reproduce: 1. Boot with 2.6.14 kernel 2. Attach FireWire device. Actual Results: Nothing. Expected Results: Drive should have been recognised and mounted. Additional info:
I see the same with a Western Digital external firewire drive. Note that it is not a problem with firewire itself or even the scsi emulation layer - the disk does show up in /proc/scsi/scsi. However no /dev/sd? devices appear and no partitions are recognized.
Is there any fix to get the firewire drive working? I have the same problem with my Maxtor 200 GB firewire HD. Regards André Fettouhi
Updates don't delete your old kernels. Pick 2.6.13-1.1532_FC4 during boot or edit /etc/grub.conf to make it your default again.
So far i noticed - everything went well with the recognition of the fw hd. things that are broken: making entries to fstab and dirs into /media etc. everything works okay befor 2.6.14... kernels.
I can't get my Sony DRX-710UL firewire CD-RW drive detected either.
same here...doesnt recognize my externel firewire hdd...on all kernels after 2.6.13-1.1532....
oh...im on an x86_64 machine and it doesnt work.
This is not resolved in the latest kernel-2.6.14-1.1653_FC4 update. Is anyone from Red Hat even reading this bug report?
Darren: yes.
(In reply to comment #9) > Darren: yes. Pete: sorry if my question sounded terse. That wasn't intended at all. But I was wondering why we hadn't had a comment asking for moreinfo (I freely admit my bug report is lacking in info, but I wasn't sure what was needed), or just something like "we are aware of what is going on and think a patch upstream will fix it". I really hope I didn't come across as a petualant user demanding stuff ... Glad to know you're on the case.
Addition to my comment 4: SMP System with kernel-smp-2.6.14-1.1644_FC4 and hotplug-2004_09_23-7. After switching fw-hd on: kernel: ohci1394: fw-host0: SelfID received, but NodeID invalid (probably new bus reset occurred): 0800FFC0 kernel: ieee1394: Error parsing configrom for node 0-00:1023 ieee1394.agent[4937]: ... no drivers for IEEE1394 product 0x/0x/0x ieee1394.agent[4946]: ... no drivers for IEEE1394 product 0x/0x/0x kernel: sbp2: $Rev: 1306 $ Ben Collins <bcollins> kernel: ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1) kernel: ieee1394: sbp2: Try serialize_io=0 for better performance kernel: scsi2 : SCSI emulation for IEEE-1394 SBP-2 Devices kernel: ieee1394: sbp2: Logged into SBP-2 device kernel: Vendor: ST316002 Model: 3A Rev: kernel: Type: Direct-Access-RBC ANSI SCSI revision: 04 kernel: SCSI device sdd: 312581808 512-byte hdwr sectors (160042 MB) kernel: sdd: asking for cache data failed kernel: sdd: assuming drive cache: write through kernel: SCSI device sdd: 312581808 512-byte hdwr sectors (160042 MB) kernel: sdd: asking for cache data failed kernel: sdd: assuming drive cache: write through kernel: sdd: sdd1 sdd2 kernel: Attached scsi disk sdd at scsi2, channel 0, id 0, lun 0 scsi.agent[4989]: enclosure at /devices/pci0000:00/0000:00:0b.0/0000:02:0b.0/fw-host0/0050770e00071002/0050770e00071002-0/host2/target2:0:0/2:0:0:0 kernel: Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0 kernel: Attached scsi generic sg1 at scsi0, channel 0, id 1, lun 0, type 0 kernel: Attached scsi generic sg2 at scsi0, channel 0, id 2, lun 0, type 0 kernel: Attached scsi generic sg3 at scsi0, channel 0, id 3, lun 0, type 5 kernel: Attached scsi generic sg4 at scsi2, channel 0, id 0, lun 0, type 14 Looking into my old rotated log files: It doesnt look like that this "ieee1394: Error parsing configrom" message appears befor. Thanks Pete PS: If more info is necessary ...
This is still a problem for me with kernel-2.6.14-1.1656_FC4. Is there something specific I/we can do/provide to help with this problem? I have a feeling that we're not seeing a resolution of this because you lack the necessary info or hardware to isolate what the problem is. I'm sure many/most of us experiencing this problem would be only to glad to help more if only we knew what was needed from us. I actually need my FireWire HDD for work, so I can't use any 2.6.14-* kernels until this is resolved.
does the 2.6.15 kernel in updates-testing work any better ?
(In reply to comment #13) > does the 2.6.15 kernel in updates-testing work any better ? I installed kernel-2.6.15-1.1824_FC4.i686 from updates-testing. No improvement. Booted with FireWire HDD unattached. This what tail -f /var/log/messages shows upon attaching FireWire HDD: Jan 13 14:28:15 excession kernel: ohci1394: fw-host0: SelfID received, but NodeID invalid (probably new bus reset occurred): 0000FFC0 Jan 13 14:28:15 excession ieee1394.agent[3156]: ... no drivers for IEEE1394 product 0x/0x/0x Jan 13 14:28:15 excession ieee1394.agent[3165]: ... no drivers for IEEE1394 product 0x/0x/0x Jan 13 14:28:15 excession kernel: SCSI subsystem initialized Jan 13 14:28:15 excession kernel: sbp2: $Rev: 1306 $ Ben Collins <bcollins> Jan 13 14:28:15 excession kernel: ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1) Jan 13 14:28:15 excession kernel: ieee1394: sbp2: Try serialize_io=0 for better performance Jan 13 14:28:15 excession kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices Jan 13 14:28:16 excession kernel: ieee1394: sbp2: Logged into SBP-2 device Jan 13 14:28:17 excession kernel: Vendor: IC35L120 Model: AVV207-0 Rev: Jan 13 14:28:17 excession kernel: Type: Direct-Access-RBC ANSI SCSI revision: 04 Jan 13 14:28:17 excession scsi.agent[3207]: enclosure at /devices/pci0000:00/0000:00:1e.0/0000:02:01.2/fw-host0/00d0b87500007594/00d0b87500007594-0/host0/target0:0:0/0:0:0:0 Jan 13 14:28:17 excession kernel: 0:0:0:0: Attached scsi generic sg0 type 14
For the sake of comparison with my comment #14, booting with kernel-2.6.13-1.1532_FC4.i686 with FireWire HDD unattached. Output of tail -f /var/log/messages on attaching FireWire HDD: Jan 13 14:42:52 excession kernel: ohci1394: fw-host0: SelfID received, but NodeID invalid (probably new bus reset occurred): 0000FFC0 Jan 13 14:42:52 excession ieee1394.agent[3930]: ... no drivers for IEEE1394 product 0x/0x/0x Jan 13 14:42:52 excession ieee1394.agent[3941]: ... no drivers for IEEE1394 product 0x/0x/0x Jan 13 14:42:53 excession kernel: SCSI subsystem initialized Jan 13 14:42:53 excession kernel: sbp2: $Rev: 1306 $ Ben Collins <bcollins> Jan 13 14:42:53 excession kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices Jan 13 14:42:54 excession kernel: ieee1394: sbp2: Logged into SBP-2 device Jan 13 14:42:54 excession kernel: Vendor: IC35L120 Model: AVV207-0 Rev: Jan 13 14:42:54 excession kernel: Type: Direct-Access ANSI SCSI revision: 06 Jan 13 14:42:54 excession scsi.agent[3983]: disk at /devices/pci0000:00/0000:00:1e.0/0000:02:01.2/fw-host0/00d0b87500007594/00d0b87500007594-0/host0/target0:0:0/0:0:0:0 Jan 13 14:42:54 excession kernel: SCSI device sda: 241254720 512-byte hdwr sectors (123522 MB) Jan 13 14:42:54 excession kernel: sda: asking for cache data failed Jan 13 14:42:54 excession kernel: sda: assuming drive cache: write through Jan 13 14:42:54 excession kernel: SCSI device sda: 241254720 512-byte hdwr sectors (123522 MB) Jan 13 14:42:54 excession kernel: sda: asking for cache data failed Jan 13 14:42:54 excession kernel: sda: assuming drive cache: write through Jan 13 14:42:54 excession kernel: sda: sda1 Jan 13 14:42:54 excession kernel: Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 Jan 13 14:42:55 excession fstab-sync[4016]: added mount point /media/IOMEGA_HDD for /dev/sda1 Jan 13 14:42:55 excession kernel: SELinux: initialized (dev sda1, type vfat), uses genfs_contexts
Same here with kernel-2.6.15-1.1824_FC4. The drive is recognized as scsi generic sgo and shows up in /proc/scsi/scsi but the sbp2 layer doesn't make the /dev/sd? device or find partitions.
By the way, the same drive above does work when connected via USB instead of firewire. It shows the same in /proc/scsi/scsi either way but with USB the /dev/sd devices are created and if the drive is connected at boot time the /md device on the drive is also detected.
Has this been fixed yet for example in FC5 (Rawhide)? Kind Regards André Fettouhi
I have the same problem with 4 pyro firewire cases. However one of them also supports USB and if I connect this drive via USB instead, then it is detected AND all the other firewire drives also suddenly become visible and work perfectly! I can then see /dev/sda through to /dev/sdd has been created. I haven't tried it, but one workaround may be just to plug in a small USB flash drive to force firewire detection...
I had similar troubles. Nothing would work right on the lastest FC3 kernel. I upgraded to FC4 and things recognized better, but like many of the comments here there was no sda,sdb. I manually did an modprobe sd_mod and then everything recognized. That's a hot plug job, right? (not totally sure) I do get a bunch of these in dmesg now: ieee1394: unsolicited response packet received - no tlabel match but the drives work perfectly. My setup is listed here: http://www.mail-archive.com/gnhlug-discuss@mail.gnhlug.org/msg12590.html
if it started working when you loaded sd_mod, then that's a problem with udev.
FYI, just tested again with latest kernel and udev from updates-released (kernel-2.6.15-1.1830_FC4, udev-071-0.FC4.2) and this is still not working.
Just tested my firewire with the latest version of the kernel and udev for FC4 and latest hal from nrpms.net and now after many weeks my firewire works again. I can see my Maxtor 200 GB disk. I didn't have to load sb_mod. Many thanks. Regards André Fettouhi
Mine is working again with kernel.i686 2.6.15-1.1830_FC4 and whatever else came along in a yum update - including udev.i386 071-0.FC4.2. Mine is a WD 250 gig and if it is connected during a reboot the md device on it is recognized too.
Interesting. It does not work on mine after the update to 2.6.15-1_1830 on an x86_64 box.
For another data point - on mine I now get sda and sdb without having to insmod sd_mod (great progress) but I don't get any RAID autodetection. There is some talk about that on debian here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=273182 I'm not sure if they sent those patches upstream such that we'd see them trickle down to fedora core.
I don't get RAID autodetection on a hotplug, but I do on a reboot. I no longer have the matching internal drive in the machine where I am testing so I am not sure if the detection happens at the right time to pair the mirrors up, but it does come up as an md device with one member present.
hello, i upgraded to kernel-2.6.15-1.1831 on an x86_64 and this is what i get: ieee1394: Node resumed: ID:BUS[0-00:1023] GUID[0030e001e0000048] scsi3 : SCSI emulation for IEEE-1394 SBP-2 Devices ieee1394: sbp2: Logged into SBP-2 device ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048] Vendor: ST340083 Model: 2A Rev: 3.03 Type: Direct-Access-RBC ANSI SCSI revision: 04 SCSI device sdb: 781422768 512-byte hdwr sectors (400088 MB) sdb: asking for cache data failed sdb: assuming drive cache: write through SCSI device sdb: 781422768 512-byte hdwr sectors (400088 MB) sdb: asking for cache data failed sdb: assuming drive cache: write through sdb: sdb1 sd 3:0:0:0: Attached scsi disk sdb sd 3:0:0:0: Attached scsi generic sg1 type 14 but the device is not accessible/mounted. this is what i get whwn turning it off: ieee1394: Node changed: 0-01:1023 -> 0-00:1023 ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[0030e001e0000048] So it sees it but i cannot access it. i tried modprobe sd_mod and that did not help.
What does that last 'not accessible' mean? Can you, as root: fdisk -l /dev/sdb and see partitions? If so, the kernel has done its job and if you have a suitable filesystem on the partition you should be able to mount it.
hello, i did fdisk -l /devsdb and /dev/sdb and it return a prompt. The device does come up in dmesg as: sbp2: $Rev: 1306 $ Ben Collins <bcollins> ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1) ieee1394: sbp2: Try serialize_io=0 for better performance scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices ieee1394: sbp2: Logged into SBP-2 device ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048] Vendor: ST340083 Model: 2A Rev: 3.03 Type: Direct-Access-RBC ANSI SCSI revision: 04 SCSI device sdb: 781422768 512-byte hdwr sectors (400088 MB) sdb: asking for cache data failed sdb: assuming drive cache: write through SCSI device sdb: 781422768 512-byte hdwr sectors (400088 MB) sdb: asking for cache data failed sdb: assuming drive cache: write through sdb: sdb1 sd 1:0:0:0: Attached scsi disk sdb sd 0:0:0:0: Attached scsi generic sg0 type 0 sd 1:0:0:0: Attached scsi generic sg1 type 14 so i have no idea when it cannot see it. it works on 2.6.13 but not of the 2.6.14's. its formated as a ext3.
The original problem here is now WFM on 2.6.15 for my hardware. I've filed bug 180708 about the md autoassembly problem which really seems like a different issue.
What else can i check to see why firewire is not auto loading on boot up for my x86_64 box? The kernel sees it.
I am not an FC user myself, therefore cannot be entirely sure where the problem really is. However I think because of reasons given for another bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175998#c15 , there is probably the loading of sd_mod by some userspace tool (hotplug script?) missing. http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=112129848913652
I am still experiencing this problem with kernel-2.6.16-1.2069_FC4.i686. On attaching external IOMEGA FireWire 120GB drive I see this in /var/log/messages: Apr 6 16:33:47 excession kernel: ohci1394: fw-host0: SelfID received, but NodeID invalid (probably new bus reset occurred): 0000FFC0 Apr 6 16:33:48 excession kernel: scsi1 : SBP-2 IEEE-1394 Apr 6 16:33:49 excession kernel: ieee1394: sbp2: Logged into SBP-2 device Apr 6 16:33:49 excession kernel: Vendor: IC35L120 Model: AVV207-0 Rev: Apr 6 16:33:49 excession kernel: Type: Direct-Access-RBC ANSI SCSI revision: 04 Apr 6 16:33:49 excession kernel: SCSI device sda: 241254720 512-byte hdwr sectors (123522 MB) Apr 6 16:33:49 excession kernel: sda: Write Protect is off Apr 6 16:33:49 excession kernel: SCSI device sda: drive cache: write back Apr 6 16:33:49 excession kernel: SCSI device sda: 241254720 512-byte hdwr sectors (123522 MB) Apr 6 16:33:49 excession kernel: sda: Write Protect is off Apr 6 16:33:49 excession kernel: SCSI device sda: drive cache: write back Apr 6 16:33:49 excession kernel: sda: sda1 Apr 6 16:33:49 excession kernel: sd 1:0:0:0: Attached scsi disk sda Apr 6 16:33:49 excession kernel: sd 1:0:0:0: Attached scsi generic sg0 type 14 Apr 6 16:33:49 excession scsi.agent[3530]: enclosure at /devices/pci0000:00/0000:00:1e.0/0000:02:01.2/fw-host0/00d0b87500007594/00d0b87500007594-0/host1/target1:0:0/1:0:0:0
Darren, this is obviously not a kernel problem. The whole stack of drivers (ohci1394--ieee1394--sbp2--scsi_mod--sd_mod) is recognizing the device. It should be possible to manually mount the partition sda1. Automount by HAL or similar userspace helpers requires a small update of those helpers as described in comment #33. (Since Linux 2.6.14, the sysfs interface of scsi_mod reports type 14 instead of type 0 for RBC disks such as most FireWire disks. See how scsi.agent prints "enclosure" as device typ in your log. This is because some old scripts wrongly associate "enclosure" with type 14 instead of type 13.)
Stefan, thanks for the info. I'm no expert but what you said makes perfect sense. However, it is still a bug. Only perhpas not a kernel bug. Should we reassign this to a different component? I'm not upgrading to FC5 for at least a month, so I'm stuck with this problem for a bit longer. When the kernels got upgraded to kernel 2.6.14 clearly something else should have been upgraded along with it -- HAL or something -- and wasn't. So, kernel guys, you'll be glad to be rid of this one. Who should we assign it to?
While all people mention HDDs, comment #5 refers to a CD-RW. This would be a different bug since the type information of CD-RWs (actually the same type identifier as CD-ROMs) did not change. If the submitter of comment #5 is still reading this: Please try a newer kernel. There were other device recognition problems fixed in Linux 2.6.15. The HDD related problems obviously result (or resulted) from - userspace helpers not loading sd_mod for SCSI device type 14, - userspace helpers not automounting filesystems on SCSI devices of type 14. Exactly which userspace helper(s) are responsible is unknown to me since I am not familiar with FC's relevant infrastructure --- /etc/hotplug.d scripts, udev scripts, HAL... (PS: Of course the root of the problems is the change in the kernel's sysfs interface, but as I mentioned elsewhere, that won't be reverted in the kernel. Alas this is a frequent issue with sysfs. Luckily, an update of userspace to use type 14 for HDDs in addition to type 0 will be safe with newer *and older* kernels. The old association of type 14 with enclosures has always been wrong but without effect.)
[This comment added as part of a mass-update to all open FC4 kernel bugs] FC4 has now transitioned to the Fedora legacy project, which will continue to release security related updates for the kernel. As this bug is not security related, it is unlikely to be fixed in an update for FC4, and has been migrated to FC5. Please retest with Fedora Core 5. Thank you.
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 bug has been mass-closed along with all other bugs that have been in NEEDINFO state for several months. Due to the large volume of inactive bugs in bugzilla, this is the only method we have of cleaning out stale bug reports where the reporter has disappeared. If you can reproduce this bug after installing all the current updates, please reopen this bug. If you are not the reporter, you can add a comment requesting it be reopened, and someone will get to it asap. Thank you.
Closing since there was an error in previous mass-close and they remained in NEEDINFO.