On Fri, 7 Mar 2008, James Bottomley wrote: > On Wed, 2008-02-27 at 15:25 -0500, Alan Stern wrote: > > On 20 Feb 2008, Alan Stern wrote: > > > > > This patch (as1036) causes the SCSI midlayer to take into account the > > > residue value provided by some low-level drivers. There's at least > > > one situation (USB mass storage with the Bulk-only transport) where > > > the specification states that it is permissible for a device to > > > indicate some of the data was not transferred correctly merely by > > > setting the residue value, without issuing a Check Condition. > > > > After a week, there hasn't been any feedback on this patch. Has it > > been accepted? Is there anything wrong with it? Is it still on a > > "to-look-at" queue? > > OK, I ran it through its paces, but it fails in testing. A very fun > failure, actually, some disks fail to appear with udev. > > The reason is they return a residue from the VPD inquiry. What your > patch actually causes is the block layer to resubmit the command with > the residue and triggers an overrun error (because the length in the > command is now much longer than the data buffer). Can you give any more details? What was the transfer length of the original command? What were the actual data length and the residue value? What were the length and data-buffer size of the resubmitted command? > The bottom line is that this patch won't work with variable length > commands like inquiry that always return a residue. You're saying that the amount of data returned is smaller that the amount requested because the data is variable length, right? Under these circumstances the block layer should not resubmit anything. That is, it should be smart enough to know that the "missing" data does not in fact exist, as opposed to not being returned because of a retryable device error. Aren't requests for things like VPD distinguished from regular data-block accesses by a flag in the request structure already? The block layer should take this flag into account when deciding whether to continue trying to transfer the "missing" data. Maybe that needs to be fixed first. 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
