Re: "aborting sbp2 command" expected in kernel.org FireWire maybe

On 2004-09-02, Pat LaVarre wrote:
> Stefan R:
>> Sbp2 should perform nearly the same under kernel 2.4 and 2.6.
>
> I haven't needed the serialize_io=1 fix for "aborting sbp2 command"
> in any
> 2.4 Linux. Is that a significant 2.6 difference I can help overcome?

There were bugs in, I believe, kernel 2.4.20 which could be
masked by serialization. The current problems with the 2.6
kernel are obviously another matter. I suspect the problems
are either rooted in how the ieee1394 transaction layer
interacts with other kernel components, or they are caused
by bugs in code that is completely outside of the 1394
drivers. But that is only my uninformed view from what I
read here.

> Should I try a different host or device or combinations thereof?

If you have access to another one, sure.

> Should I try CONFIG_IEEE1394_VERBOSEDEBUG?

I am not sure if that reveals necessary information. If you
start to dig deeper, get the people at linux1394-devel and
perhaps at linux-scsi involved. (SBP-2 may by only a strange
curiousity from the linux-scsi POV though.)

>> Sbp2 should perform nearly the same under kernel 2.4 and 2.6. In
>> fact, I
>> found once that reading from CD-ROM is much improved under kernel 2.6
>> compared to 2.4.
>
> Thruput runs 2X slower than 2.4 Linux here in the 2.6.6 Linux of
> Knoppix 3.4,
> no matter serialize_io=1 or not. By contrast, here serialize_io=1
> makes the
> newer 2.6.7 Linux of Knoppix 3.6 consistently run at speed, even at
> runlevel
> 5 with GUI.

A factor of 2 must be caused by some unnoticed error conditions.

I understand that non-serialized IO is meant to give better
throuhput, however in a test I made several months ago I did
not notice relevant differences with and without serialization.

> Is that trouble of interest for a 1394 developer? (It's not of
> interest for
> me: I'll just use 1394 in 2.6 only since Linux 2.6.7.)

The developers are interested in the current kernel & drivers.

> http://www.linux1394.org/viewcvs/
>
> Can't get there, sorry . 60s timeout seen today, by now via two
> different
> ISP's.

The Subversion server is down at the moment. It happens.
It is not the fault of viewcvs or of some ISP this time.

> SCSI over every other kind of cable looks ok. PATAPI, USB, PATAPI,
> SPI,
> SATAPI, ...
>
> Somehow FireWire alone depresses thruput and makes bugs of 2.6 Linux
> SCSI
> more commonly significant?

>> 44 MByte/s ... sounds enormous,
>
> Not enormous to my ear today in 2004:

I meant, the *difference* between un-optimized and gapcount-
optimized throughput sounds enormous.

> 44 MB/s = 2.64 GB/min = 88% of the 50 MB/s = 3 GB/min bus clock of
> the 400
> MHz FireWire, out of which 100% we subtract all the normal overheads.
...
>> http://marc.theaimsgroup.com/?l=linux1394-devel&m=109128028930225 ,

The overhead listed in that posting is of course only FireWire
architecture related. There comes an additional small overhead
by the SBP-2 protocol (which I am not familiar with), and
properties of the Linux implementation (block device access
provided by sd-mod and other protocol drivers which cooperate
with scsi, sbp2, ieee1394, ohci1394...).

> dmesg counts two CPU here,
...
> In grep 1394 I see your .config agrees with my 2.6.9-rc1-bk7:

Would you mind trying a uni-processor kernel? Also have a look on
other general config options. The 1394 drivers' config is not that
spectacular in itself.

-- 
Stefan Richter
http://arcgraph.de/sr/
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
mailing list Linux1394-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-user