Re: BUG: SCSI: usb storage SDHC card doesn't work in 2.6.27-rc1

Alan Stern
2008-07-31T15:10:36Z

On Wed, 30 Jul 2008, Pete Zaitcev wrote:

> Perhaps I misunderstand how our SCSI stack works. The code in ub is
> simpler, it deals with 3 values at the end of transfer:
> Lasked is how much we asked for
> Lgot is how much was transferred
> Lresid is the reported residue
>
> So, ub checks if the following is true:
> Lasked = Lgot + Lresid
>
> If device fails this check, you can assume that it's just not set up
> to report the residue correctly and so, the danger of valid residue
> that you outlined becomes rather academic.

This algorithm is wrong. See the description under Case (4) or (5) in
6.7.2 of the Bulk-Only spec:

The device may send fill data to pad up to a total of
dCBWDataTransferLength.

So it's legal to have Lgot == Lasked and Lresid > 0. There are devices
which really do this.

(It may seem pointless to add the padding. However for reasons that
aren't clear, the spec requires the device to STALL the bulk-in
endpoint if the padding isn't present -- and many devices don't like to
STALL bulk endpoints. Similar reasoning applies to the case of OUT
transfers.)

> The reason I do it this way is, I've seen a device which reported
> a correct residue until the first long read, and then residue was
> miscalculated due to a 16-bit wrap (it did transfer right data though).
> I think it's one of those which are explicitly blacklisted these
> days, but I cannot remember.

I hope it's blacklisted!

Alan Stern