[PATCH] storage: Don't scan target 7 for SCM USB-SCSI converters
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= 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= 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=0x7
[ 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.0 +0100
+++ linux-3.17-rc6/drivers/usb/storage/usb.c2014-09-22 12:11:19.0
+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
Re: [PATCH] storage: Don't scan target 7 for SCM USB-SCSI converters
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= 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= 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=0x7
[ 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] storage: Don't scan target 7 for SCM USB-SCSI converters
On Mon, 22 Sep 2014 10:17:02 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: On Mon, 22 Sep 2014, Mark wrote: 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. ... 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 compiled a kernel with that change and it did solve the problem. Obviously it wasn't a very big problem, but the bus scan should be about 1/3 second faster now. Mark -- 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
