Bug 141917 - ieee1394: sbp2: aborting sbp2 command
ieee1394: sbp2: aborting sbp2 command
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-05 20:02 EST by mark
Modified: 2015-01-04 17:13 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-04 09:11:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description mark 2004-12-05 20:02:37 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:
sdd: Spinning up disk.........ready
SCSI device sdd: 1470500 512-byte hdwr sectors (753 MB)
sdd: Write Protect is off
sdd: Mode Sense: 40 00 10 00
SCSI device sdd: drive cache: write back
SCSI device sdd: 1470500 512-byte hdwr sectors (753 MB)
sdd: Write Protect is off
sdd: Mode Sense: 40 00 10 00
SCSI device sdd: drive cache: write back
 sdd:<3>Buffer I/O error on device sdd, logical block 0
Buffer I/O error on device sdd, logical block 1
Buffer I/O error on device sdd, logical block 0
Buffer I/O error on device sdd, logical block 1
Buffer I/O error on device sdd, logical block 367624
Buffer I/O error on device sdd, logical block 367624
Buffer I/O error on device sdd, logical block 0
Buffer I/O error on device sdd, logical block 1
 unable to read partition table
SCSI device sdd: 1470500 512-byte hdwr sectors (753 MB)
sdd: Write Protect is off
sdd: Mode Sense: 40 00 10 00
SCSI device sdd: drive cache: write back
SCSI device sdd: 1470500 512-byte hdwr sectors (753 MB)
sdd: Write Protect is off
sdd: Mode Sense: 40 00 10 00
SCSI device sdd: drive cache: write back
 sdd: sdd4
ieee1394: sbp2: aborting sbp2 command
Read (10) 00 00 00 11 80 00 00 f8 00
kjournald starting.  Commit interval 5 seconds
EXT3-fs warning: mounting fs with errors, running e2fsck is recommended
EXT3 FS on sdd4, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
SELinux: initialized (dev sdd4, type ext3), uses xattr
ieee1394: sbp2: aborting sbp2 command
Read (10) 00 00 13 19 40 00 00 08 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 00 00 20 00 00 28 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 00 4f c0 00 00 18 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 00 00 20 00 00 08 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 00 00 30 00 00 18 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 00 00 50 00 00 08 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 00 0f 38 00 00 08 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 00 97 60 00 00 08 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 04 00 38 00 00 08 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 04 00 68 00 00 10 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 09 b1 48 00 00 08 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 00 0f 68 00 00 18 00
ieee1394: sbp2: aborting sbp2 command
Read (10) 00 00 07 10 a0 00 00 20 00
ieee1394: sbp2: aborting sbp2 command
Prevent/Allow Medium Removal 00 00 00 01 00
ieee1394: sbp2: aborting sbp2 command
Prevent/Allow Medium Removal 00 00 00 01 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 00 00 20 00 00 10 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 09 b1 48 00 00 08 00
ieee1394: sbp2: aborting sbp2 command
Prevent/Allow Medium Removal 00 00 00 01 00
ieee1394: sbp2: aborting sbp2 command
Prevent/Allow Medium Removal 00 00 00 01 00
ieee1394: sbp2: aborting sbp2 command
Prevent/Allow Medium Removal 00 00 00 01 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 00 6f c0 00 00 20 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 00 6f c0 00 00 20 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 05 1b 98 00 00 08 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 05 1b e0 00 00 08 00
ieee1394: sbp2: aborting sbp2 command
Prevent/Allow Medium Removal 00 00 00 01 00
ieee1394: sbp2: aborting sbp2 command
Prevent/Allow Medium Removal 00 00 00 01 00
ieee1394: sbp2: aborting sbp2 command
Prevent/Allow Medium Removal 00 00 00 01 00
ieee1394: sbp2: aborting sbp2 command
Prevent/Allow Medium Removal 00 00 00 01 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 05 21 68 00 00 08 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 05 21 70 00 00 08 00
ieee1394: sbp2: aborting sbp2 command
Prevent/Allow Medium Removal 00 00 00 01 00
ieee1394: sbp2: aborting sbp2 command
Prevent/Allow Medium Removal 00 00 00 01 00
ieee1394: sbp2: aborting sbp2 command
Write (10) 00 00 05 24 c0 00 00 08 00


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

How reproducible:
Always

Steps to Reproduce:
1. insert removable ieee1394 media into drive
2. copy files from drive to local drive
3.
    

Actual Results:  see above

Expected Results:  copying to continue more quickly

Additional info:

using stock FC3 kernel
Comment 1 mark 2004-12-05 20:15:00 EST
i forgot to add that on my PIII/500 machine with 768MB RAM i get 47%
load (according to gnome-system-monitor), 9% processor utilization and
20MB files take like 20mins to copy. i realize my machine is no speed
demon but with nothing else running in the background, such a small
file size, and that much ram i'd expect much better performance. hope
this helps.
Comment 2 Dave Jones 2005-07-15 16:48:53 EDT
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 3 Jeremy Rosengren 2005-09-19 00:02:09 EDT
I started seeing these errors sporadically using kernel 2.6.12-1.1376_FC3smp. 
This is the first fc3 kernel update in about 4 or 5 where this problem has
surfaced again.

Previously I had been running kernel kernel-smp-2.6.11-1.35_FC3.

Sep 18 22:57:11 clunker kernel: ieee1394: sbp2: aborting sbp2 command
Sep 18 22:57:11 clunker kernel: scsi3 : destination target 0, lun 0
Sep 18 22:57:11 clunker kernel:         command: Read (10): 28 00 11 30 1d 0f 00
00 28 00
Comment 4 Chris Read 2005-10-01 17:36:22 EDT
This problem has appeared again in kernel-2.6.13-1.1526_FC4. Always
reproducable, just try copy more than about 2GB of data onto the firewire disk
and you get the "aborting sbp2". Reverting to kernel-2.6.12-1.1456_FC4 makes the
problem go away, so it's not a hardware fault.

Oct  1 18:09:54 xfiles kernel: ieee1394: sbp2: aborting sbp2 command
Oct  1 18:09:54 xfiles kernel: scsi1 : destination target 0, lun 0
Oct  1 18:09:54 xfiles kernel:         command: Write (10): 2a 00 02 69 27 e7 00
00 08 00
Oct  1 18:10:04 xfiles kernel: ieee1394: sbp2: aborting sbp2 command
Oct  1 18:10:04 xfiles kernel: scsi1 : destination target 0, lun 0
Oct  1 18:10:04 xfiles kernel:         command: Test Unit Ready: 00 00 00 00 00 00
Oct  1 18:10:04 xfiles kernel: ieee1394: sbp2: aborting sbp2 command
Oct  1 18:10:04 xfiles kernel: scsi1 : destination target 0, lun 0
Oct  1 18:10:04 xfiles kernel:         command: Write (10): 2a 00 02 69 47 ef 00
00 08 00
Comment 5 Jeremy Rosengren 2005-10-21 13:32:19 EDT
The latest FC3 update kernel, 2.6.12-1.1380_FC3smp, so far seems to have
addressed this issue.  I was able to copy a 2.2 GB file between two firewire
drives on this system without any sbp2 errors.  Additional normal reads/writes
on that system's firewire disks have also not triggered any errors since last night.
Comment 6 Jeremy Rosengren 2005-10-22 00:31:25 EDT
I guess I spoke too soon.  I've just seen 5 of these errors, all from serving
some large files via NFS.
Comment 7 Jeremy Rosengren 2005-12-22 23:24:15 EST
After upgrading the server with these errors to FC4, I thought the problem was
resolved, since I hadn't seen any for a couple of weeks.  As of a couple of days
ago, however, I'm seeing them.

Dec 22 19:11:16 clunker kernel: ieee1394: sbp2: aborting sbp2 command
Dec 22 19:11:16 clunker kernel: scsi5 : destination target 0, lun 0
Dec 22 19:11:16 clunker kernel:         command: Write (10): 2a 00 00 00 00 3f
00 00 01 00

Linux clunker 2.6.14-1.1653_FC4smp #1 SMP Tue Dec 13 21:46:01 EST 2005 i686 i686
i386 GNU/Linux

Should this bug be reassigned to FC4?

Any other information gathering I can do to finally get this problem resolved? 
The last time I had a kernel that didn't exhibit this problem was the last
2.6.11 kernel for FC3.
Comment 8 Dave Jones 2006-01-16 17:39:02 EST
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 9 Jeremy Rosengren 2006-01-16 17:52:47 EST
Some additional data points from my own limited testing:

This bug has occurred in FC4, and seemed to occur with the combination of XFS
filesystem and firewire hard drive.  After seeing sbp2: abort errors in the FC4
kernels as recent as 1653, I moved those filesystems to ext3 and have since not
seen any sbp2 errors at all under similar workloads.
Comment 10 Dave Jones 2006-01-17 00:33:05 EST
curious. The underlying filesystem shouldn't make any difference to an error
like this.  I'll leave this open for now in case it reoccurs, but it's possible
that one of the upstream rebases fixed it at some point, as various fixes did go
into the firewire code over the last few months.
Comment 11 Dave Jones 2006-02-03 02:34:57 EST
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 09:11:21 EDT
Closing per previous comment.

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