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? 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.
storage: Don't scan target 7 for SCM USB-SCSI converters
SCM-based USB-SCSI converters always have SCSI ID 7. Set max_id to 7
(instead of 8) to avoid attempting to have the converter issue INQUIRY
commands to itself when scanning the bus.
Signed-off-by: Mark Knibbs <ma...@clara.co.uk>
---
diff -up linux-3.17-rc6/drivers/usb/storage/usb.c.orig
linux-3.17-rc6/drivers/usb/storage/usb.c
--- linux-3.17-rc6/drivers/usb/storage/usb.c.orig 2014-09-21
23:43:02.000000000 +0100
+++ linux-3.17-rc6/drivers/usb/storage/usb.c 2014-09-22 12:11:19.000000000
+0100
@@ -980,8 +980,8 @@ int usb_stor_probe2(struct us_data *us)
if (us->fflags & US_FL_SINGLE_LUN)
us->max_lun = 0;
- if (!(us->fflags & US_FL_SCM_MULT_TARG))
- us_to_host(us)->max_id = 1;
+ /* Avoid scanning non-existent targets */
+ us_to_host(us)->max_id = (us->fflags & US_FL_SCM_MULT_TARG) ? 7 : 1;
/* Find the endpoints and calculate pipe values */
result = get_pipes(us);
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
