Bug 141917

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.

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.

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

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

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.

I guess I spoke too soon.  I've just seen 5 of these errors, all from serving
some large files via NFS.

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.

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.

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.

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.

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