Bugzilla – Bug 144673
unable to access fire wire hdd via creative labs SB Audigy 4 port
Last modified: 2006-04-01 11:07:52 UTC
I have an Creative SB Audigy where I attach my IEEE external HD (Trekstor). It was working fine with SUSE Pro 9.3. After reinstalling my system with 10.1 beta1 (no update) the device is no longer working. Kernel seems to detect the firewire port just fine (see dmesg log) and SBP2 finds the device but it appears to be offline. All sorts of resetting tried with no success. DMESG log: ACPI: PCI Interrupt 0000:02:0b.2[B] -> GSI 20 (level, low) -> IRQ 209 ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[209] MMIO=[fbffb800-fbffbfff] Max Packet=[2048] IR/IT contexts=[4/8] ieee1394: The root node is not cycle master capable; selecting a new root node and resetting... ieee1394: Host added: ID:BUS[0-01:1023] GUID[00023c0201002c69] ieee1394: Node added: ID:BUS[0-00:1023] GUID[0010100300000000] ieee1394: Node changed: 0-01:1023 -> 0-02:1023 ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1) ieee1394: sbp2: Try serialize_io=0 for better performance scsi3 : SBP-2 IEEE-1394 ieee1394: sbp2: Node 0-00:1023: Using 36byte inquiry workaround ieee1394: sbp2: Logged into SBP-2 device ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048] Vendor: Initio Model: 0KLAT80 Rev: 2.05 Type: Direct-Access ANSI SCSI revision: 00 SCSI device sdb: 781422768 512-byte hdwr sectors (400088 MB) sdb: Write Protect is off sdb: Mode Sense: 86 0b 00 02 ieee1394: sbp2: aborting sbp2 command sd 3:0:0:0: command: Mode Sense (10): 5a 00 08 00 00 00 00 00 af 00 ieee1394: sbp2: hpsb_node_write failed. ieee1394: sbp2: Bus reset in progress - rejecting command ieee1394: sbp2: reset requested ieee1394: sbp2: Generating sbp2 fetch agent reset ieee1394: sbp2: hpsb_node_write failed. ieee1394: sbp2: Bus reset in progress - rejecting command sd 3:0:0:0: scsi: Device offlined - not ready after error recovery sdb: got wrong page sdb: assuming drive cache: write through sd 3:0:0:0: Attached scsi disk sdb sd 3:0:0:0: Attached scsi generic sg1 type 0
still present in beta 2
I have uploaded a few older kernels. No idea if any of them will boot for you, but maybe we can narrow it down. ftp://ftp.suse.com/pub/people/olh/kernel/bug144673/
Note, a kernel older than 2.6.5 won't boot on 10.1 because of the changed udev interface. To boot such kernel one either needs to install the udev.rpm from 10.0 (but that will not work for 2.6.14 or newer) or disable all commands which contain the string "udev" in the scripts in /etc/init.d, then you just use the static devs.rpm which is thankfully still supplied. You might also try the latest kernel of the day: ftp://ftp.suse.com/pub/projects/kernel/kotd/i386/HEAD/ If that does not fix it, you can try the latest -mm kernel, which is currently here: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc4/2.6.16-rc4-mm1/ We do not have any ieee1394-specific patches at the moment, so if something firewire does does not work with our kernels, it likely happens with mainline too and bugzilla.kernel.org is then the quickest and responible bugzilla. If that does not work, it must be reported in kernel.bugzilla.org, (best by the reporter, since he may be needed for questions). My own bugreport regarding a firewire-disk (sbp2 driver) there was fixed within 12 hours by the experts for the mainline kernel. Granded: The respective subsystem maintainers also had affected disks and were already working on it.
That was a great idea :-) I encountered the same problem on Redhat Fedora 5 test 2 and so it had to be a kernel issue. Stefan Richter (sbp2 maintainer) posted it to the kernel.org bugzilla site and it got a workaround and possible fix already. What you need to do is to tell scsi_mod to use a certain inquiry hack on the IEEE bridge inside of my hard disk shelf. The dev_param flag needs to be set to 8192. That will fix the issue. The patch should go into the 2.6.16 kernel (if possible) to automatically put my device bridge on the blacklist, so this param will no longer be necessary in the future. I leave it up to you to leave this entry open until the kernel bug is fixed or to close it right away. Thanks guys. Ron
test with 10.1 beta6 or later kernel
tested with beta 9, works! Thanks :-)