On Sunday 28 July 2013 15:28:52 Alan Stern wrote: > On Sat, 27 Jul 2013, Stuart Foster wrote: > > On 07/27/13 20:34, Alan Stern wrote: > > > On Sat, 27 Jul 2013, Stuart Foster wrote: > > >> On 07/27/13 15:58, Alan Stern wrote: > > >>> On Sat, 27 Jul 2013, Stuart Foster wrote: > > >>>> 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. > > >>> > > >>> On Sat, 27 Jul 2013, Ed Tomlinson wrote: > > >>>> 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. > > >>> > > >>> 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? > > > > > > 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). > > > > 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 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 -- 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
