On Wed, 30 Jul 2008 17:28:49 -0400 (EDT), Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> > > + if (bcs->Status == US_BULK_STAT_OK &&
> > > + scsi_get_resid(srb) == 0 &&
> > > + ((srb->cmnd[0] == INQUIRY &&
> > > + transfer_length == 36) ||
> > > + (srb->cmnd[0] == READ_CAPACITY &&
> > > + transfer_length == 8))) {
> > > + us->flags |= US_FL_IGNORE_RESIDUE;
> >
> > Why do you do this for INQUIRY and READ_CAPACITY only?
> > Why not do it for any command?
>
> Because those are the only two commands for which I'm reasonably
> certain the device should never return a nonzero residue with Okay
> status. For other commands there might be a valid positive residue --
> although if there is then the device should also return Check Condition
> status (the spec is unclear on this point).
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.
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.
-- Pete
--
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
