Bug 140111 - FIrewire/IEEE1394 HDD caddy recognized, but inaccessible
Summary: FIrewire/IEEE1394 HDD caddy recognized, but inaccessible
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-19 20:28 UTC by Alex Butcher
Modified: 2015-01-04 22:12 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-04 13:10:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/var/log/messages (9.80 KB, text/plain)
2004-11-19 20:29 UTC, Alex Butcher
no flags Details
/var/log/messages after recent udev/hal updates (3.82 KB, text/plain)
2004-12-04 21:56 UTC, Alex Butcher
no flags Details
/var/log/messages with force_inquiry_hack=1 (10.01 KB, text/plain)
2004-12-07 20:42 UTC, Alex Butcher
no flags Details
/var/log/messages with serialize_io and force_inquiry_hack (8.84 KB, text/plain)
2004-12-08 19:23 UTC, Alex Butcher
no flags Details
/var/log/messages with 2.6.12-1.1372_FC3 kernel (4.01 KB, text/plain)
2005-07-16 07:06 UTC, Alex Butcher
no flags Details

Description Alex Butcher 2004-11-19 20:28:36 UTC
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.

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
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Attached devices:
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: WDC WD80 Model: 0JB-00CRA1       Rev:
  Type:   Direct-Access                    ANSI SCSI revision: 06

WDC WD80        0JB-00CRA1

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

How reproducible:

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

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).

Comment 1 Alex Butcher 2004-11-19 20:29:47 UTC
Created attachment 107087 [details]

Comment 2 Alex Butcher 2004-11-28 19:49:28 UTC
Still not recognised with 2.6.9-1.681_FC3.

Comment 3 Alex Butcher 2004-12-04 21:56:55 UTC
Created attachment 107906 [details]
/var/log/messages after recent udev/hal updates

All updates as of 4 Dec 2004 applied.

Comment 4 Alex Butcher 2004-12-07 20:42:01 UTC
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. :(

Comment 5 Alex Butcher 2004-12-08 19:23:44 UTC
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.

Comment 6 Alex Butcher 2004-12-17 15:59:05 UTC
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.

Comment 7 Dave Jones 2005-07-15 17:57:09 UTC
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.

Comment 8 Alex Butcher 2005-07-16 07:05:14 UTC
Still doesn't work with all FC3 updates as of 16 Jul 2005 (inc. kernel

/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
#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
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

Comment 9 Alex Butcher 2005-07-16 07:06:48 UTC
Created attachment 116833 [details]
/var/log/messages with 2.6.12-1.1372_FC3 kernel

Comment 10 Dave Jones 2006-01-16 22:24:09 UTC
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.

Comment 11 Dave Jones 2006-02-03 05:28:12 UTC
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.

Comment 12 John Thacker 2006-05-04 13:10:07 UTC
Closing per previous two comments.

Comment 13 Alex Butcher 2007-03-11 08:13:24 UTC
# 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
# 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

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