----- "Alan Stern" <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Sun, 11 Oct 2009, Benjamin Herrenschmidt wrote:
>
> >
> > > Further REQUEST SENSE commands therefore requested 96 bytes of
> data
> > > instead of the standard 18 bytes. With LUN 0 this worked okay.
> But
> > > with LUN 1 it didn't; the device reported a failure of the REQUEST
>
> > > SENSE. This is what caused usb-storage to issue the device
> reset.
> > >
> > > After the reset usb-storage continued to ask for 96 bytes of
> sense
> > > data, and LUN 1 continued to fail the commands. Hence the
> repeated
> > > resets.
> >
> > Maybe a better approach would be to go back to 18 bytes when it
> fails,
> > what do you think ?
>
> We certainly could do that. But should we turn off the SANE_SENSE
> flag
> at the same time?
No I don't think its a good idea to turn off SANE_SENSE in this situation. Here is a patch similar to Ben Herrenschmidt's but will not turn off SANE_SENSE just because a transport failure.
Retry with short sense when SANE_SENSE fails.
Signed-off-by: Ben Efros <ben@xxxxxxxxxxxxx>
--- linux-2.6.31.1/drivers/usb/storage/transport.c 2009-09-24 08:45:25.000000000 -0700
+++ linux-2.6.31.1.new/drivers/usb/storage/transport.c 2009-10-11 08:06:26.000000000 -0700
@@ -696,7 +696,7 @@ void usb_stor_invoke_transport(struct sc
/* device supports and needs bigger sense buffer */
if (us->fflags & US_FL_SANE_SENSE)
sense_size = ~0;
-
+Retry_Sense:
US_DEBUGP("Issuing auto-REQUEST_SENSE\n");
scsi_eh_prep_cmnd(srb, &ses, NULL, 0, sense_size);
@@ -723,6 +723,12 @@ void usb_stor_invoke_transport(struct sc
if (temp_result != USB_STOR_TRANSPORT_GOOD) {
US_DEBUGP("-- auto-sense failure\n");
+ if ((us->fflags & US_FL_SANE_SENSE) &&
+ sense_size != US_SENSE_SIZE) {
+ sense_size = US_SENSE_SIZE;
+ US_DEBUGP("-- retry without SANE_SENSE\n");
+ goto Retry_Sense;
+ }
/* we skip the reset if this happens to be a
* multi-target device, since failure of an
* auto-sense is perfectly valid
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
