From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: I have a couple of ATA discs housed in Sumvision USB 2.0/Firewire enclosures (second down on <http://www.sumvision.com.cn/enclosure.shtml>). They work perfectly if attached via USB, but do not work if attached via a Sumvision Firewire card (VT6306 (Rev. 46)-based). To avoid any problems with modules not being present, I performed the following before switching the caddy on: # modprobe raw1394 # modprobe ohci1394 # modprobe video1394 # modprobe sd_mod # modprobe sg # modprobe sbp2 /var/log/messages is included as an attachment. Once /dev/sda was created, I tried running 'fdisk -l /dev/sda' a couple of times. The first time, it hung for a bit, then returned with no output. The second time it returned almost instantly (strace says that open("/dev/sda") returned -ENXIO). This equipment is new, so I've not previously tried to get it working with any other Linux distribution. Additionally, I have a Toshiba S3000-S214 laptop with a TI 1394 controller (also running FC3, though without any updates right now) and the caddies don't work via firewire there either. lspci: 02:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46) (prog-if 10 [OHCI]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 32, Cache Line Size 08 Interrupt: pin A routed to IRQ 11 Region 0: Memory at e2008000 (32-bit, non-prefetchable) [size=2K] Region 1: I/O ports at 8000 [size=128] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA ME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- /proc/scsi/scsi: Attached devices: Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: WDC WD80 Model: 0JB-00CRA1 Rev: Type: Direct-Access ANSI SCSI revision: 06 /proc/scsi/sg/device_strs: WDC WD80 0JB-00CRA1 Version-Release number of selected component (if applicable): 2.6.9-1.678_FC3 How reproducible: Always Steps to Reproduce: 1. Attach firewire caddy via firewire card 2. Power on caddy 3. Observe as device is recognized as made available as a pseudo-SCSI device. Actual Results: Device was inaccessible. Expected Results: Device was accessible. Additional info: All updates as ov 19 Nov applied, bar sound-juicer and system-config-users (i.e. latest official FC3 udev).
Created attachment 107087 [details] /var/log/messages
Still not recognised with 2.6.9-1.681_FC3.
Created attachment 107906 [details] /var/log/messages after recent udev/hal updates All updates as of 4 Dec 2004 applied.
Created attachment 108067 [details] /var/log/messages with force_inquiry_hack=1 Ended up causing a full crash eventually. Even magic SysRq didn't work. :(
Created attachment 108141 [details] /var/log/messages with serialize_io and force_inquiry_hack followed by oops after rmmod'ing sbp2 when it was apparent it wasn't going to work anyway.
From googling around (e.g. <http://tinyurl.com/523so>), it would appear that the firmware image loaded on my caddies is too old (2003/6/19) to have working firewire. It seems that 2004/04/22 is probably about the earliest version for which Firewire can be expected to work. Firmware and updater tools can be found at <http://member.newsguy.com/~siccos/PL3507%20Firmware.htm>, but these have not been tested by me (my caddies do not have user-programmable flash!), so use at your own risk. If anyone at RH/Fedora thinks there's hope for getting these caddies working with Firewire, even with an old firmware image, I'm happy to test things as they arise. Otherwise, I guess the sensible thing is to close the bugzilla.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
Still doesn't work with all FC3 updates as of 16 Jul 2005 (inc. kernel 2.6.12-1.1372_FC3). /var/log/messages seems to show slight improvement, attached. After plugging in device and syslogging finishes: # lsmod | grep 1394 ohci1394 39945 0 ieee1394 303545 2 sbp2,ohci1394 # lsmod | grep sd sd_mod 20289 0 scsi_mod 146313 4 aic7xxx,scsi_transport_spi,sbp2,sd_mod # lsmod | grep sbp sbp2 25289 1 ieee1394 303545 2 sbp2,ohci1394 scsi_mod 146313 4 aic7xxx,scsi_transport_spi,sbp2,sd_mod # cat /etc/modprobe.conf alias eth0 e100 alias snd-card-0 snd-intel8x0 options snd-card-0 index=0 install snd-intel8x0 /sbin/modprobe --ignore-install snd-intel8x0 && /usr/sbin/alsactl restore >/dev/null 2>&1 || : remove snd-intel8x0 { /usr/sbin/alsactl store >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-intel8x0 #orig #alias usb-controller ehci-hcd #alias usb-controller1 ohci-hcd #alias usb-controller2 uhci-hcd alias usb-controller ohci-hcd alias usb-controller1 uhci-hcd alias usb-controller2 ehci-hcd alias ieee1394-controller ohci1394 # force_inquiry_hack allows login, but still gets read errors, even with serialize options sbp2 force_inquiry_hack=1 serialize_io=1 alias scsi_hostadapter sbp2 alias char-major-81 bttv #install bttv /sbin/modprobe msp3400 tuner tvmixer tvaudio btaudio bttv options bttv combfilter=1 lumafilter=1 tuner=1 card=0 pll=1 radio=1 autoload=1 bttv_verbose=2 options tuner type=1 debug=0 options tvmixer devnr=0 options tvaudio tea6300=1 tda8425=0 tda9840=0 tda9850=0 tda9855=0 tda9873=0 tea6420=0 pic16c54=0 debug=0 options it87 force_it87=9191,0x290 alias scsi_hostadapter1 aic7xxx options loop max_loop=32
Created attachment 116833 [details] /var/log/messages with 2.6.12-1.1372_FC3 kernel
This is a mass-update to all currently open Fedora Core 3 kernel bugs. Fedora Core 3 support has transitioned to the Fedora Legacy project. Due to the limited resources of this project, typically only updates for new security issues are released. As this bug isn't security related, it has been migrated to a Fedora Core 4 bug. Please upgrade to this newer release, and test if this bug is still present there. This bug has been placed in NEEDINFO_REPORTER 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. Thank you.
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) 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_REPORTER 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. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
Closing per previous two comments.
# lsmod | grep '1394\|scsi\|sbp' video1394 22437 0 dv1394 23845 0 raw1394 31557 0 sbp2 28229 0 scsi_mod 141805 4 sg,sd_mod,sbp2,libata ohci1394 39173 2 video1394,dv1394 ieee1394 299929 5 video1394,dv1394,raw1394,sbp2,ohci1394 # uname -r 2.6.19-1.2911.6.5_1.fc6.cubbi_suspend2 # dmesg [...] ieee1394: Current remote IRM is not 1394a-2000 compliant, resetting... ieee1394: Error parsing configrom for node 0-00:1023 ieee1394: Node changed: 0-00:1023 -> 0-01:1023 ieee1394: Node resumed: ID:BUS[0-00:1023] GUID[0050770e000000c5] scsi1 : SBP-2 IEEE-1394 ieee1394: sbp2: Error logging into SBP-2 device - timed out sbp2: probe of 0050770e000000c5-0 failed with error -16