[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux1394-devel
Subject:    Re: [Bug 16577] Firewire drive throughput slow, hangs,
From:       Stefan Richter <stefanr () s5r6 ! in-berlin ! de>
Date:       2010-08-23 11:24:16
Message-ID: 4C725A60.1040003 () s5r6 ! in-berlin ! de
[Download RAW message or body]

(Cc linux1394-devel, quoting in full for the list)

bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=16577
> 
> --- Comment #12 from bt@lawngnome.org  2010-08-23 03:32:08 ---
> (In reply to comment #10)
>> sysfs interface.  Here is an example which I wrote down a while ago when I
>> needed it:
>> # echo 9216 > /sys/module/scsi_mod/parameters/scsi_logging_level
> 
> yes, unfortunately my primary disk is also on scsi.  
> 
>> Does the disk work well under OS X?
> 
> unfortunately yes, the disk does work well under OS X, especially on the
> laptop's embedded firewire interface.  it also works semi-well, but pops a few
> "out of transaction labels" messages into kernel and i slower, when using the
> LaCie expresscard. 

Which hints that the card may be troublesome.  And that in turn agrees with my
experience that all TSB82AA2 + TSB81BA3 sooner or later exhibit random
malfunctions of lesser or greater severity, primarily together with 1394b
(FireWire 800) devices but in some cases also with 1394a (FireWire 400)
devices.  My guess is that the TSB81BA3 is to blame.  (In contrast to
TSB81BA3D and TSB81BA3E which seem to be fine.)

> I also have another (sigh) LaCie drive on a fw400-only enclosure.  this drive
> does not work any better or worse than the rugged fw800 drive I have been
> mentioning, it just fails differently.  

I have a LaCie Little Disk myself, 2x FireWire 400 + USB 2.0 + button version,
based on the OXUF934DSA bridge chip.  This works without troubles.  Just now I
tested it on my LaCie 1394b CardBus card, with an otherwise disabled PCI card
added as a 12V bus power provider.  Works speedy and reliable.  hdparm -tT
reports > 35 MB/s, just like when the Little Disk is plugged into other cards.

As I mentioned, this LaCie CardBus card here is useless with any 1394b
devices.  I don't have a LaCie 1394b disk to test though.  But I am certain
that one or some of the 1394b disks which I have here have the same bridge
chip as whichever one sticks in your LaCie Rugged Disk; though there may be
firmware differences of course.

> I have tried chaining them together in various ways, like:
> 
> [fw800 card]--fw800:fw400 cable--[LaCie fw400]--fw400--[Rugged]
> [fw800 card]--fw800---[Rugged]---[fw400]----[Lacie fw400]
> 
> etc
> 
> however the results are all the same, stalls, bad throughput, etc.

How do you supply power to the disks?  Please do not use USB power cables.
These may work with some luck but more likely introduce random I/O errors, if
not outright discovery/ inquiry failures.

>> Another thing that you could test is to put the OS X laptop (if it is an Apple
>> laptop, not a Hackintosh) into target disk mode (press and hold the "t" key
>> while you power the laptop up), the put Linux laptop -- Apple laptop --
>> FireWire disk into a chain and try to use the latter.  I.e. let the Apple
>> laptop act as an expensive FireWire repeater.  Perhaps this also works if you
>> plug this chain together and then power the Apple laptop up normally or have
>> it hibernating or whatever.
> 
> this sounds like an interesting test but unless if I'm missing something
> obvious, unfortunately I can't do it with my test Apple laptop because it only
> has 1 fw800 port.  To make it a repeater I'd need 2 for this setup.

Oh, I forgot that newer Apple laptops only have a single FireWire port again.
Still, you could at least include it in a test as a reliable bus power
provider, if you do not have a dedicated PSU for either the CardBus card or
the LaCie disk(s) or do not trust the reliability of such a PSU.  Of course
you need to get OS X as SBP-2 initiator out of the picture, e.g. by starting
the laptop in SBP-2 target mode as mentioned.

> I will look around at work and see if I can find a Mac desktop which has
> multiple native firewire interfaces, and report back if I can determine
> anything from making the Mac host the devices.

A test with an Apple desktop as repeater --- or any other kind of repeater ---
is probably not going to reveal anything useful now that even the test with
the LaCie FireWire 400 disk as repeater did not improve matters.

One other thought:  If you have the experience and time for doing so, you
could try to rebuild your 2.6.34(.?) kernel from source, with latest firewire
driver updates patched in:  http://user.in-berlin.de/~s5r6/linux1394/updates/
The 2.6.34.y patch series in there applies to 2.6.34.1 or any later 2.6.34.y
sources.  If your 2.6.34-020634-generic is still a plain 2.6.34 kernel (check
the first few lines in Makefile), the one patch in
http://user.in-berlin.de/~s5r6/linux1394/merged/in_2.6.34.1/ needs to be
applied to make the combo patch or patch series in updates/ applicable.

I do not remember anything in these driver changes since 2.6.34 that is of
obvious importance to your bug report, but an actual test would be good if you
can manage.  I hope there are build instructions somewhere at ubuntu.com.
-- 
Stefan Richter
-=====-==-=- =--- =-===
http://arcgraph.de/sr/

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
mailing list linux1394-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-devel
[prev in list] [next in list] [prev in thread] [next in thread]