Kernel 3.10.3 "reset SuperSpeed USB device number 2 using xhci_hcd"

DISCUSSION Alan Stern 5 participants 10 messages Jul 28, 2013 – Aug 2, 2013 2 messages not in the archive SCSI

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Alan Stern

author

2013-07-28 19:28 UTC #1 lore raw

Quoted 51 lines · Stuart Foster

Quoted 35 lines · Alan Stern
Quoted 18 lines · Stuart Foster
Quoted 17 lines · Alan Stern
Quoted 5 lines · Stuart Foster
Hi,
I have started having problems with an external USB 3 diskdrive, the problems started when I moved from the 3.10.2 kernel to 3.10.3. The machine is a ASUS M5A97 PRO, BIOS 1604.
Quoted 3 lines · Ed Tomlinson
Hi
Same problem here with 3.10.3. Dmesg filtered with 'hci'.
Each of you, please post a usbmon trace showing what happens when the drive is plugged in.
Quoted 6 lines
Quoted 3 lines
Alan Stern
Hi Alan
Herewith the log you requested.
The trace shows that something is sending an invalid INQUIRY command (one with a 512-byte transfer length) to the drive. Normally such things are done by user programs, but in this case it looks more like the command came from somewhere in the kernel. I have no idea where.
Did you change anything besides the kernel when going from 3.10.2 to 3.10.3?
Quoted 8 lines
If you boot now into a 3.10.2 kernel, does the drive work?
What happens if you plug the drive into a USB-2 port? (I expect it will make no difference at all.)
Alan Stern
Hi Alan,
The config between 3.10.2 and 3.10.3 did not change.
The drive works correctly on 3.10.2 (I usually keep the previous kernel available just in case).

Quoted 8 lines

On 3.10.3 the drive fails in a similar manner when plugged into a USB-2 port.
For interest I have tried the USB-3 drive in the USB-2 ports on an IBM thinkpad R51 laptop that is also running 3.10.3 and that fails also.
Conversely I have tried a USB-2 drive on both the IBM and my ASUS machine and that works fine on 3.10.3 in all available USB ports.

Thank you. I was able to duplicate the problem on my own machine and track down the bug.

It was introduced by commit 98dcc2946adb (SCSI: sd: Update WRITE SAME heuristics). This commit adds a call to scsi_get_vpd_page() in sd_read_write_same() without first checking sd_try_extended_inquiry(). As noted in the latter routine, VPD inquiries will crash some devices.

Martin, this bug needs to be fixed in 3.11. As far as the stable kernels are concerned, the best thing for now may simply be to revert it.

Alan Stern

A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.44L0.1307281505410.18237-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org

Stuart Foster

2013-07-29 07:21 UTC #3 lore raw

Quoted 70 lines · Alan Stern

Quoted 51 lines · Stuart Foster
Quoted 35 lines · Alan Stern
Quoted 18 lines · Stuart Foster
Quoted 17 lines · Alan Stern
Quoted 5 lines · Stuart Foster
Hi,
I have started having problems with an external USB 3 diskdrive, the problems started when I moved from the 3.10.2 kernel to 3.10.3. The machine is a ASUS M5A97 PRO, BIOS 1604.
Quoted 3 lines · Ed Tomlinson
Hi
Same problem here with 3.10.3. Dmesg filtered with 'hci'.
Each of you, please post a usbmon trace showing what happens when the drive is plugged in.
Quoted 6 lines
Quoted 3 lines
Alan Stern
Hi Alan
Herewith the log you requested.
The trace shows that something is sending an invalid INQUIRY command (one with a 512-byte transfer length) to the drive. Normally such things are done by user programs, but in this case it looks more like the command came from somewhere in the kernel. I have no idea where.
Did you change anything besides the kernel when going from 3.10.2 to 3.10.3?
Quoted 8 lines
If you boot now into a 3.10.2 kernel, does the drive work?
What happens if you plug the drive into a USB-2 port? (I expect it will make no difference at all.)
Alan Stern
Hi Alan,
The config between 3.10.2 and 3.10.3 did not change.
The drive works correctly on 3.10.2 (I usually keep the previous kernel available just in case).
Quoted 8 lines
On 3.10.3 the drive fails in a similar manner when plugged into a USB-2 port.
For interest I have tried the USB-3 drive in the USB-2 ports on an IBM thinkpad R51 laptop that is also running 3.10.3 and that fails also.
Conversely I have tried a USB-2 drive on both the IBM and my ASUS machine and that works fine on 3.10.3 in all available USB ports.
Thank you. I was able to duplicate the problem on my own machine and track down the bug.
It was introduced by commit 98dcc2946adb (SCSI: sd: Update WRITE SAME heuristics). This commit adds a call to scsi_get_vpd_page() in sd_read_write_same() without first checking sd_try_extended_inquiry(). As noted in the latter routine, VPD inquiries will crash some devices.

Quoted 7 lines

Martin, this bug needs to be fixed in 3.11. As far as the stable kernels are concerned, the best thing for now may simply be to revert it.
Alan Stern

Hi Alan,

Thanks for the update I will look forward to a solution.

regards

Stuart Foster
--
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

Martin K. Petersen

2013-07-29 15:06 UTC #4 lore raw

In reply to Alan Stern

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Alan" == Alan Stern <[email protected]> writes:

Alan,

Alan> It was introduced by commit 98dcc2946adb (SCSI: sd: Update WRITE Alan> SAME heuristics). This commit adds a call to scsi_get_vpd_page() Alan> in sd_read_write_same() without first checking
Alan> sd_try_extended_inquiry(). As noted in the latter routine, VPD Alan> inquiries will crash some devices.

Is REPORT SUPPORTED OPERATION CODES generally safe on USB devices?

The reason I didn't wrap the WRITE SAME heuristics in sd_try_extended_inquiry() like I have done with most of the other VPDs is that there are a ton of older SPI/SAS/FC devices that support WRITE SAME just fine.

Alan> As far as the stable kernels are concerned, the best thing for now Alan> may simply be to revert it.

No go. The above commit fixes issues for somebody else.

I could add an explicit check to the sd_read_write_same() function. But how about we do the following instead?

Signature · 11 lines

Martin K. Petersen	Oracle Linux Engineering


SCSI: Don't attempt to send extended INQUIRY command if skip_vpd_pages is set

If a device has the skip_vpd_pages flag set we should simply fail the
scsi_get_vpd_page() call.

Signed-off-by: Martin K. Petersen <[email protected]>
Cc: Alan Stern <[email protected]>
Cc: [email protected]

drivers/scsi/scsi.c +3 -0

index 3b1ea34..eaa808e 100644
@@ -1031,6 +1031,9 @@ int scsi_get_vpd_page(struct scsi_device *sdev, u8 page, unsigned char *buf,
 {
 	int i, result;
 
+	if (sdev->skip_vpd_pages)
+		goto fail;
+
 	/* Ask for all the pages supported by this device */
 	result = scsi_vpd_inquiry(sdev, buf, 0, buf_len);
 	if (result)

Alan Stern

author

2013-07-29 15:23 UTC #5 lore raw

Quoted 11 lines · Martin K. Petersen

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Alan" == Alan Stern <[email protected]> writes:
Alan,
Alan> It was introduced by commit 98dcc2946adb (SCSI: sd: Update WRITE Alan> SAME heuristics). This commit adds a call to scsi_get_vpd_page() Alan> in sd_read_write_same() without first checking
Alan> sd_try_extended_inquiry(). As noted in the latter routine, VPD Alan> inquiries will crash some devices.
Is REPORT SUPPORTED OPERATION CODES generally safe on USB devices?

Broadly speaking, practically nothing is safe on USB devices. :-) The general rule is: If Windows XP doesn't use the command then it will crash something.

In the case of these bug reports, the scsi_report_opcode() call returns -EINVAL.

Quoted 6 lines

The reason I didn't wrap the WRITE SAME heuristics in sd_try_extended_inquiry() like I have done with most of the other VPDs is that there are a ton of older SPI/SAS/FC devices that support WRITE SAME just fine.

Quoted 7 lines

Alan> As far as the stable kernels are concerned, the best thing for now Alan> may simply be to revert it.
No go. The above commit fixes issues for somebody else.
I could add an explicit check to the sd_read_write_same() function. But how about we do the following instead?

Stuart and Ed, does Martin's patch fix your problem?

Alan Stern

Martin K. Petersen

2013-07-29 15:28 UTC #6 lore raw

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Alan" == Alan Stern <[email protected]> writes:

Alan> In the case of these bug reports, the scsi_report_opcode() call Alan> returns -EINVAL.

Oh, right. Because I actually do an explicit SCSI version check in scsi_report_opcode(). That's OK, then...

Signature · 1 line

Martin K. Petersen	Oracle Linux Engineering

Stuart Foster

2013-07-29 16:33 UTC #7 lore raw

In reply to Alan Stern

Quoted 30 lines · Alan Stern

Quoted 11 lines · Martin K. Petersen
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Alan" == Alan Stern <[email protected]> writes:
Alan,
Alan> It was introduced by commit 98dcc2946adb (SCSI: sd: Update WRITE Alan> SAME heuristics). This commit adds a call to scsi_get_vpd_page() Alan> in sd_read_write_same() without first checking
Alan> sd_try_extended_inquiry(). As noted in the latter routine, VPD Alan> inquiries will crash some devices.
Is REPORT SUPPORTED OPERATION CODES generally safe on USB devices?
Broadly speaking, practically nothing is safe on USB devices. :-) The general rule is: If Windows XP doesn't use the command then it will crash something.
In the case of these bug reports, the scsi_report_opcode() call returns -EINVAL.
Quoted 9 lines
The reason I didn't wrap the WRITE SAME heuristics in sd_try_extended_inquiry() like I have done with most of the other VPDs is that there are a ton of older SPI/SAS/FC devices that support WRITE SAME just fine.
Alan> As far as the stable kernels are concerned, the best thing for now Alan> may simply be to revert it.

Quoted 10 lines

Quoted 4 lines
No go. The above commit fixes issues for somebody else.
I could add an explicit check to the sd_read_write_same() function. But how about we do the following instead?
Stuart and Ed, does Martin's patch fix your problem?
Alan Stern

Hi Alan,

The patch is good for me.

thanks

Stuart Foster

Alan Stern

author

2013-07-30 18:44 UTC #8 lore raw

Quoted 10 lines · Stuart Foster

Quoted 5 lines
Stuart and Ed, does Martin's patch fix your problem?
Alan Stern
Hi Alan,
The patch is good for me.
thanks

There also have been positive reports from Marc Meledandri and Philipp Dreimann.

Martin, please submit your patch for inclusion in the stable kernels as soon as possible. Or I can submit it for you.

Alan Stern

Martin K. Petersen

Acked-by Alan Stern Tested-by Stuart Foster

2013-07-31 02:58 UTC #9 lore raw

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Alan" == Alan Stern <[email protected]> writes:

Quoted 5 lines · Stuart Foster

Quoted 5 lines
Hi Alan,
The patch is good for me.
thanks

Alan> There also have been positive reports from Marc Meledandri and Alan> Philipp Dreimann.

Alan> Martin, please submit your patch for inclusion in the stable Alan> kernels as soon as possible.

James?

[PATCH] SCSI: Don't attempt to send extended INQUIRY command if skip_vpd_pages is set

If a device has the skip_vpd_pages flag set we should simply fail the scsi_get_vpd_page() call.

Signed-off-by Martin K. Petersen <[email protected]>

Acked-by Alan Stern <[email protected]>

Tested-by Stuart Foster <[email protected]>

Cc [email protected]

drivers/scsi/scsi.c +3 -0

index 3b1ea34..eaa808e 100644
@@ -1031,6 +1031,9 @@ int scsi_get_vpd_page(struct scsi_device *sdev, u8 page, unsigned char *buf,
 {
 	int i, result;
 
+	if (sdev->skip_vpd_pages)
+		goto fail;
+
 	/* Ask for all the pages supported by this device */
 	result = scsi_vpd_inquiry(sdev, buf, 0, buf_len);
 	if (result)

Alan Stern

author

2013-07-31 14:50 UTC #10 lore raw

Quoted 17 lines · Martin K. Petersen

James?
[PATCH] SCSI: Don't attempt to send extended INQUIRY command if skip_vpd_pages is set
If a device has the skip_vpd_pages flag set we should simply fail the scsi_get_vpd_page() call.
Signed-off-by Martin K. Petersen <[email protected]>
Acked-by Alan Stern <[email protected]>
Tested-by Stuart Foster <[email protected]>
Cc [email protected]
drivers/scsi/scsi.c +0 -0
index 3b1ea34..eaa808e 100644

drivers/scsi/scsi.c int scsi_get_vpd_page(struct scsi_device *sdev, u8 page, unsigned char *buf, · line 1039

Quoted 9 lines

drivers/scsi/scsi.c +3 -0

@@ -1031,6 +1031,9 @@ int scsi_get_vpd_page(struct scsi_device *sdev, u8 page, unsigned char *buf,
 {
 	int i, result;
 
+	if (sdev->skip_vpd_pages)
+		goto fail;
+
 	/* Ask for all the pages supported by this device */
 	result = scsi_vpd_inquiry(sdev, buf, 0, buf_len);
 	if (result)

Thanks, Martin.

Alan Stern

Peter Wu

2013-08-02 10:32 UTC #11 lore raw

In reply to Alan Stern

Quoted 64 lines · On Sunday 28 July 2013 15:28:52 Alan Stern wrote:

Quoted 46 lines · Stuart Foster
Quoted 31 lines · Alan Stern
Quoted 13 lines · Stuart Foster
Quoted 12 lines · Alan Stern
Quoted 5 lines · Stuart Foster
Hi,
I have started having problems with an external USB 3 diskdrive, the problems started when I moved from the 3.10.2 kernel to 3.10.3. The machine is a ASUS M5A97 PRO, BIOS 1604.
Quoted 3 lines · Ed Tomlinson
Hi
Same problem here with 3.10.3. Dmesg filtered with 'hci'.
Quoted 8 lines
Quoted 4 lines
Each of you, please post a usbmon trace showing what happens when the drive is plugged in.
Alan Stern
Hi Alan
Herewith the log you requested.
The trace shows that something is sending an invalid INQUIRY command (one with a 512-byte transfer length) to the drive. Normally such things are done by user programs, but in this case it looks more like the command came from somewhere in the kernel. I have no idea where.
Did you change anything besides the kernel when going from 3.10.2 to 3.10.3?
Quoted 6 lines
If you boot now into a 3.10.2 kernel, does the drive work?
What happens if you plug the drive into a USB-2 port? (I expect it will make no difference at all.)
Alan Stern
Hi Alan,
The config between 3.10.2 and 3.10.3 did not change.
The drive works correctly on 3.10.2 (I usually keep the previous kernel available just in case).
Quoted 8 lines
On 3.10.3 the drive fails in a similar manner when plugged into a USB-2 port.
For interest I have tried the USB-3 drive in the USB-2 ports on an IBM thinkpad R51 laptop that is also running 3.10.3 and that fails also.
Conversely I have tried a USB-2 drive on both the IBM and my ASUS machine and that works fine on 3.10.3 in all available USB ports.
Thank you. I was able to duplicate the problem on my own machine and track down the bug.
It was introduced by commit 98dcc2946adb (SCSI: sd: Update WRITE SAME heuristics). This commit adds a call to scsi_get_vpd_page() in sd_read_write_same() without first checking sd_try_extended_inquiry(). As noted in the latter routine, VPD inquiries will crash some devices.

Quoted 5 lines

Martin, this bug needs to be fixed in 3.11. As far as the stable kernels are concerned, the best thing for now may simply be to revert it.
Alan Stern

Hi,

I am also affected by this bug, this one is broken:
scsi 7:0:0:0: Direct-Access Kingston DataTraveler 2.0 1.00 PQ: 0 ANSI: 4
sd 7:0:0:0: Attached scsi generic sg2 type 0
sd 7:0:0:0: [sdb] 15138816 512-byte logical blocks: (7.75 GB/7.21 GiB)
sd 7:0:0:0: [sdb] Write Protect is off
sd 7:0:0:0: [sdb] Mode Sense: 2f 00 00 00
sd 7:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA ** USB device removed here after ten seconds **
usb 2-1.2: USB disconnect, device number 7
sd 7:0:0:0: [sdb] Attached SCSI removable disk

This device is still working on the same kernel:
scsi 14:0:0:0: Direct-Access SanDisk Cruzer Blade 8.02 PQ: 0 ANSI: 0 CCS
sd 14:0:0:0: Attached scsi generic sg2 type 0
sd 14:0:0:0: [sdb] 15695871 512-byte logical blocks: (8.03 GB/7.48 GiB) sd 14:0:0:0: [sdb] Write Protect is off
sd 14:0:0:0: [sdb] Mode Sense: 45 00 00 08
sd 14:0:0:0: [sdb] No Caching mode page present
sd 14:0:0:0: [sdb] Assuming drive cache: write through
sd 14:0:0:0: [sdb] No Caching mode page present
sd 14:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1
sd 14:0:0:0: [sdb] No Caching mode page present
sd 14:0:0:0: [sdb] Assuming drive cache: write through
sd 14:0:0:0: [sdb] Attached SCSI removable disk

Reverting 98dcc2946adb on top of v3.11-rc3-207-g64ccccf works for me (tested through QEMU with USB passthrough). I noticed this issue since 3.11-rc2 (previous kernel was 3.10.0).

I've two affected USB 2.0 sticks (in a USB 2.0 port) and one that is still working:
- "1516:1213 CompUSA" - broken
- "0951:1665 Kingston Technology" - broken
- "0781:5567 SanDisk Corp. Cruzer Blade" - working

If it helps, this is when the affected USB stick is plugged in:

# cat /proc/$(pidof usb-storage)/stack
[<ffffffffa0566f21>] usb_stor_msg_common+0xf1/0x170 [usb_storage]
[<ffffffffa0567349>] usb_stor_bulk_transfer_buf+0x59/0xa0 [usb_storage]
[<ffffffffa056763c>] usb_stor_Bulk_transport+0x15c/0x330 [usb_storage]
[<ffffffffa0567e18>] usb_stor_invoke_transport+0x38/0x550 [usb_storage]
[<ffffffffa0566b4e>] usb_stor_transparent_scsi_command+0xe/0x10 [usb_storage]
[<ffffffffa0568c63>] usb_stor_control_thread+0x173/0x290 [usb_storage]
[<ffffffff8106ef1a>] kthread+0xea/0xf0
[<ffffffff815b5fdc>] ret_from_fork+0x7c/0xb0
[<ffffffffffffffff>] 0xffffffffffffffff

Let me know if I should provide further details like usbmon or test something.

Regards,
Peter