sbp2 firewire failure on kernels 2.6.1-1.61, 2.6.2-1.81

Michel Alexandre Salim salimma at fastmail.fm
Wed Feb 18 08:02:51 UTC 2004


On 17 Feb 2004 16:05:24 -0300, "Alexandre Oliva" <aoliva at redhat.com>
said:
> On Feb 17, 2004, "Michel Alexandre Salim" <salimma at fastmail.fm> wrote:
> 
> > What is the status of firewire support on FC2-devel?
> 
> I had some minor issues with 2.6.1-1.65 that prevented it from
> recognizing my Maxtor 5000DV early in the boot (I had mkinitrd
> --with=sd_mod --with=sbp2, such that I could do RAID 1 to the external
> disk), but those were all fixed in 2.6.2.
> 
That should not be necessary if I am not doing RAID/LVM, right? Firewire
initialization takes place after LVM, so it should work.

If I have the drive turned on at boot time, kudzu takes a long time to
complete, generating the following dmesg entries:

ieee1394: sbp2: Logged into SBP-2 device
ieee1394: sbp2: Node 0-00:1023: Max speed [S400] - Max payload [2048]
  Vendor: ST312002  Model: 2A                Rev:
  Type:   Direct-Access                      ANSI SCSI revision: 06
SCSI device sdb: 234467403 512-byte hdwr sectors (120047 MB)
sdb: asking for cache data failed
sdb: assuming drive cache: write through
 sdb:<6>kudzu: numerical sysctl 1 23 is obsolete.
ieee1394: sbp2: aborting sbp2 command
Read (10) 00 0d f9 b0 48 00 00 03 00
ieee1394: sbp2: aborting sbp2 command
Test Unit Ready 00 00 00 00 00
ieee1394: sbp2: reset requested
ieee1394: sbp2: Generating sbp2 fetch agent reset
ieee1394: sbp2: aborting sbp2 command
Test Unit Ready 00 00 00 00 00
ieee1394: sbp2: reset requested
ieee1394: sbp2: Generating sbp2 fetch agent reset
ieee1394: sbp2: aborting sbp2 command
Test Unit Ready 00 00 00 00 00
ieee1394: sbp2: reset requested
ieee1394: sbp2: Generating sbp2 fetch agent reset
ieee1394: sbp2: aborting sbp2 command
Test Unit Ready 00 00 00 00 00
scsi: Device offlined - not ready after error recovery: host 1 channel 0
id 0 lun 0
SCSI error : <1 0 0 0> return code = 0x50000
end_request: I/O error, dev sdb, sector 234467400
Buffer I/O error on device sdb, logical block 234467400
Buffer I/O error on device sdb, logical block 234467401
Buffer I/O error on device sdb, logical block 234467402
scsi1 (0:0): rejecting I/O to offline device
Buffer I/O error on device sdb, logical block 234467400
Buffer I/O error on device sdb, logical block 234467401
Buffer I/O error on device sdb, logical block 234467402
 unsupported disk (sdb)
 sdb1
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0

-----------

the problem is probably not specific to ieee1394, actually, since I get
similar errors connecting the drive to USB. Not to mention the drive
geometry appears different too (under 2.4 fdisk reports one extra
cylinder for USB2 if I recall correctly, and I had to take care not to
allocate it to a partition).

rmmod-ing sbp2 after those errors results consistently in segfaults,
here's the dump:

ieee1394: sbp2: Logged out of SBP-2 device
Unable to handle kernel paging request at virtual address 6b6b6c1f
 printing eip:
f096d7c5
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<f096d7c5>]    Not tainted
EFLAGS: 00010246
EIP is at scsi_device_put+0x5/0x40 [scsi_mod]
eax: 6b6b6b6b   ebx: ecf5e89c   ecx: 00000000   edx: ecf5eddc
esi: ef0297d8   edi: ef08675c   ebp: ef0298fc   esp: d7083f04
ds: 007b   es: 007b   ss: 0068
Process rmmod (pid: 20048, threadinfo=d7082000 task=d7f448a0)
Stack: ef0297d8 f090e890 00000008 ef0297d8 ef08675c ef08675c 00000000
f090deb8
       ee6a7970 f091388c f091388c c0253086 f09138f0 f09138f0 c02530a8
       f0adc6cc
       f0adc680 c0253321 f0913894 f091388c 00000000 c02536f4 f0913a00
       c0363920
Call Trace:
 [<f090e890>] sbp2_remove_device+0x180/0x190 [sbp2]
 [<f090deb8>] sbp2_remove+0x38/0x50 [sbp2]
 [<c0253086>] device_release_driver+0x56/0x60
 [<c02530a8>] driver_detach+0x18/0x30
 [<c0253321>] bus_remove_driver+0x51/0x90
 [<c02536f4>] driver_unregister+0x14/0x3a
 [<f0910aaa>] sbp2_module_exit+0xa/0x14 [sbp2]
 [<c0145c3b>] sys_delete_module+0x11b/0x190
 [<c0164b00>] unmap_vma+0x30/0xa0
 [<c016513d>] do_munmap+0x1ad/0x280
 [<c0177018>] __fput+0x98/0xf0
 [<c010c49f>] syscall_call+0x7/0xb
 
Code: 8b 80 b4 00 00 00 8b 00 85 c0 74 0b ff 88 00 01 00 00 83 38

----

Any idea? Should I bugzilla this, and perhaps forward it to linux1394
maintainers?

Going to try a newer kernel first, but before that, resize my Windows
partition so I could triple boot FC1, FC2T1 and XP.

- Michel

-- 
http://www.fastmail.fm - Or how I learned to stop worrying and
                          love email again





More information about the fedora-devel-list mailing list