Re: [PATCH v2] SCSI: detect missing data for INQUIRY

[James Smart <James.Smart@Emulex.Com>]

Checking the payload like this is really hokey - but probably works.
Have we lost all notion from the LLDD on what the actual payload length 
was (calculated by expected transfer length and resid) ?  Seems like a 
much better idea than just checking contents.

-- james s

Alan Stern wrote:
> This patch (as1154b) fixes a problem in scsi_probe_lun(): The function
> doesn't check whether the device has actually sent back any INQUIRY
> data!  The patch adds a test to see if the result buffer is still
> empty after the command has been executed.
> 
> This enables the Thecus N2050 storage device to work.  The firmware on
> that device starts up strangely; it sends no data in response to the
> initial INQUIRY, and it sends the INQUIRY information in response to
> the followup REQUEST SENSE!  But after that it works better, so
> retrying the INQUIRY is enough to get it going.
> 
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> 
> ---
> 
> Index: usb-2.6/drivers/scsi/scsi_scan.c
> ===================================================================
> --- usb-2.6.orig/drivers/scsi/scsi_scan.c
> +++ usb-2.6/drivers/scsi/scsi_scan.c
> @@ -602,6 +602,14 @@ static int scsi_probe_lun(struct scsi_de
>                                     (sshdr.ascq == 0))
>                                         continue;
>                         }
> +               } else {
> +                       /*
> +                        * If the first four bytes are all 0 then probably
> +                        * nothing was transferred.  Try again.
> +                        */
> +                       if ((inq_result[0] | inq_result[1] |
> +                                       inq_result[2] | inq_result[3]) == 0)
> +                               continue;
>                 }
>                 break;
>         }
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>