On Mon, 22 Sep 2014, Mark wrote:
> Hi,
>
> When using an SCM-based USB-SCSI converter, access to target 7 is attempted
> after scanning targets 0 to 6 during the bus scan. The SCSI ID of the
> converter is hard-wired to 7 so there will never be a target there. I'm
> proposing a small patch to usb_stor_probe2() so target 7 is not accessed;
> see below.
>
> Log output for first of the kernel's four attempts to issue INQUIRY to target
> 7:
> [ 282.740356] *** thread awakened
> [ 282.740372] Command INQUIRY (6 bytes)
> [ 282.740384] bytes:
> [ 282.740408] 12 00 00 00 24 00
> [ 282.740433] Bulk Command S 0x43425355 T 0x24 L 36 F 128 Trg 7 LUN 0 CL 6
> [ 282.740446] xfer 31 bytes
> [ 282.742909] Status code 0; transferred 31/31
> [ 282.742925] -- transfer complete
> [ 282.742937] Bulk command transfer result=0
> [ 282.742958] xfer 36 bytes, 1 entries
> [ 282.746072] Status code -32; transferred 0/36
> [ 282.746087] clearing endpoint halt for pipe 0xc0010280
> [ 282.746115] rq=01 rqtype=02 value=0000 index=82 len=0
> [ 282.750084] result = 0
> [ 282.750113] Bulk data transfer result 0x2
> [ 282.750126] Attempting to get CSW...
> [ 282.750138] xfer 13 bytes
> [ 282.753372] Status code 0; transferred 13/13
> [ 282.753387] -- transfer complete
> [ 282.753400] Bulk status result = 0
> [ 282.753414] Bulk Status S 0x53425355 T 0x24 R 36 Stat 0x1
> [ 282.753427] -- transport indicates command failure
> [ 282.753439] Issuing auto-REQUEST_SENSE
> [ 282.753455] Bulk Command S 0x43425355 T 0x25 L 18 F 128 Trg 7 LUN 0 CL 6
> [ 282.753689] xfer 31 bytes
> [ 282.756707] Status code 0; transferred 31/31
> [ 282.756721] -- transfer complete
> [ 282.756733] Bulk command transfer result=0
> [ 282.756746] xfer 18 bytes, 1 entries
> [ 282.761027] Status code -32; transferred 0/18
> [ 282.761044] clearing endpoint halt for pipe 0xc0010280
> [ 282.761059] rq=01 rqtype=02 value=0000 index=82 len=0
> [ 282.763976] result = 0
> [ 282.763999] Bulk data transfer result 0x2
> [ 282.764012] Attempting to get CSW...
> [ 282.764027] xfer 13 bytes
> [ 282.767519] Status code 0; transferred 13/13
> [ 282.767547] -- transfer complete
> [ 282.767560] Bulk status result = 0
> [ 282.767574] Bulk Status S 0x53425355 T 0x25 R 36 Stat 0x1
> [ 282.767587] -- auto-sense failure
> [ 282.767600] scsi cmd done, result=0x70000
> [ 282.767665] *** thread sleeping
>
>
> In usb_stor_probe2() there is:
> if (!(us->fflags & US_FL_SCM_MULT_TARG))
> us_to_host(us)->max_id = 1;
>
> Change that to:
> us_to_host(us)->max_id = (us->fflags & US_FL_SCM_MULT_TARG) ? 7 : 1;
>
> Is that enough?
Try it and see.
> I noticed that usb_stor_control_thread() has this code:
> /* reject if target != 0 or if LUN is higher than
> * the maximum known LUN
> */
> else if (us->srb->device->id &&
> !(us->fflags & US_FL_SCM_MULT_TARG)) {
> usb_stor_dbg(us, "Bad target number (%d:%llu)\n",
> us->srb->device->id,
> us->srb->device->lun);
> us->srb->result = DID_BAD_TARGET << 16;
> }
>
> Would there be any reason/benefit to also change the check there? The patch
> below is just for the usb_stor_probe2() change.
I don't think this will make any difference.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
