AW: Crash/hung task in usb-storage thread

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Thu, 23 May 2019, Schmid, Carsten wrote:
> 
> > Hi USB maintainers,
> >
> > we recently have seen a problem with usb-storage when trying to read
> from a device.
> > This happened on a 4.14.86 kernel.
> >
> > The kernel's dmesg shows: (log has been submitted via DLT)
> > 1200.862250 kernel: usb 1-3.1: reset high-speed USB device number 10
> using xhci_hcd
> > 1285.466289 kernel: usb 1-3.1: reset high-speed USB device number 10
> using xhci_hcd
> > 1291.911286 kernel: usb-storage: Error in queuecommand_lck: us->srb =
> ffff9d66b02e3528
> > 1292.018079 kernel: usb-storage: Error in queuecommand_lck: us->srb =
> ffff9d66b02e3528
> > 1292.043073 kernel: usb-storage: Error in queuecommand_lck: us->srb =
> ffff9d66b02e3528
> > 1292.069078 kernel: usb-storage: Error in queuecommand_lck: us->srb =
> ffff9d66b02e3528
> > 1292.093066 kernel: usb-storage: Error in queuecommand_lck: us->srb =
> ffff9d66b02e3528
> 
> Since there haven't been any substantive change to usb-storage since
> 4.14 was released, there's a good chance this is a problem with
> xhci-hcd.
> 
> Is this problem repeatable?  Can you collect a usbmon trace showing
> what happens when the problem occurs?
> 
Unfortunately this happened in the field on a test drive.
I don't have access to the device.
So, no, can't be reproduced by now.

> > There has been a similar bug being fixed in 3.17 kernel series, maybe the
> bug has been re-introduced?
> > https://bugzilla.kernel.org/show_bug.cgi?id=88341
> 
> That is _extremely_ unlikely.
> 
Looked into the history of that bug report.
Strange: no fix is menioned.
Reported: 2014-17-11
Remark on 2019-02-26
No hint to a real fix.
It simply disappeared ...

> > As USB seems to be the causing subsystem, i submit this query here.
> >
> > Any idea what could cause this?
> 
> The particular error message you got means that the SCSI layer asked
> usb-storage to send a command to the device before the previous command
> was completed.  But without more information there's no way to tell why
> it did this.
> 
> Alan Stern
That's at least a hint i can forward to the vendor.

Thanks Alan, 
Carsten



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux