]> pilppa.com Git - linux-2.6-omap-h63xx.git/commit
firewire: fw-sbp2: set single-phase retry_limit
authorJarod Wilson <jwilson@redhat.com>
Fri, 7 Mar 2008 06:43:01 +0000 (01:43 -0500)
committerStefan Richter <stefanr@s5r6.in-berlin.de>
Thu, 13 Mar 2008 23:56:59 +0000 (00:56 +0100)
commit51f9dbef5be41f3ff6000c874741a3a357f9bad7
tree9ee2f70c6ce881624fc35aabc0129cafeb8fee0c
parent11bf20ad028880a56689f086bfbabfd88b2af38b
firewire: fw-sbp2: set single-phase retry_limit

Per the SBP-2 specification, all SBP-2 target devices must have a BUSY_TIMEOUT
register. Per the 1394-1995 specification, the retry_limt portion of the
register should be set to 0x0 initially, and set on the target by a logged in
initiator (i.e., a Linux host w/firewire controller(s)).

Well, as it turns out, lots of devices these days have actually moved on to
starting to implement SBP-3 compliance, which says that retry_limit should
default to 0xf instead (yes, SBP-3 stomps directly on 1394-1995, oops).

Prior to this change, the firewire driver stack didn't touch retry_limit, and
any SBP-3 compliant device worked fine, while SBP-2 compliant ones were unable
to retransmit when the host returned an ack_busy_X, which resulted in stalled
out I/O, eventually causing the SCSI layer to give up and offline the device.

The simple fix is for us to set retry_limit to 0xf in the register for all
devices (which actually matches what the old ieee1394 stack did).

Prior to this change, a hard disk behind an SBP-2 Prolific PL-3507 bridge chip
would routinely encounter buffer I/O errors and wind up offlined by the SCSI
layer. With this change, I've encountered zero I/O failures moving tens of GB
of data around.

Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
drivers/firewire/fw-sbp2.c