On Mon, 2008-10-27 at 12:18 -0400, Alan Stern wrote:
> This patch (as1154) 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@xxxxxxxxxxxxxxxxxxx>
>
> ---
>
> This should get into 2.6.28.
>
>
> 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,13 @@ static int scsi_probe_lun(struct scsi_de
> (sshdr.ascq == 0))
> continue;
> }
> + } else {
> + /*
> + * Additional Length and Vendor fields missing
> + * probably means nothing was transferred. Try again.
> + */
> + if (inq_result[4] == 0 && inq_result[8] == 0)
> + continue;
Really, no.
A legitimate minimal response from a device is zero in the additional
length field. If it does that, then the vendor field is bound to be
zero as well.
About the best we can do is check the first four fields. For them to be
all zero, it would have to be a minimal response SCSI-1 device (RDF of
zero) ... hopefully they're all dead by now.
James
--
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
