On Tue, 10 Jun 2014, James Bottomley wrote: > From the trace below, this looks to be a USB issue (USB added to cc): > the scsi error handler thread is waiting for usb storage to complete the > reset. It's a 3.14.5 kernel, so the previous reset hang because of > spurious sense requests should be fixed. > > James > > > On Tue, 2014-06-10 at 16:50 +0000, bugzilla-daemon@xxxxxxxxxxxxxxxxxxx > wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=77631 > > > > Bug ID: 77631 > > Summary: task scsi_eh_6:537 blocked for more than 120 seconds. > > Product: IO/Storage > > Version: 2.5 > > Kernel Version: 3.14.6 > > Hardware: All > > OS: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: SCSI > > Assignee: linux-scsi@xxxxxxxxxxxxxxx > > Reporter: mikhail.v.gavrilov@xxxxxxxxx > > Regression: No > > > > Created attachment 138941 > > --> https://bugzilla.kernel.org/attachment.cgi?id=138941&action=edit > > kernel log > > > > task scsi_eh_6:537 blocked for more than 120 seconds. This line from earlier in the kernel log is highly suspicious: > [ 46.330470] usb-storage: Error in queuecommand_lck: us->srb = ffff88080c532600 This means that the SCSI midlayer called the queuecommand routine twice with no intervening completion, even though the maximum queue depth is only 1. Mikhail, is this bug reproducible? If it is, can you post a usbmon trace showing the events leading up to the bug? Does the bug occur if the device is plugged into a USB-2 bus rather than a USB-3 bus? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
