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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
