(Adding Tejun Heo who was assigned on still-open bugzilla #93581 which is about SATA but seems terribly related.) On Wed, 15 Nov 2017 16:43:14 -0500 Jérôme Carretero <cJ-ko@xxxxxxxxxxx> wrote: > Hi Hans, > > > Tests are currently undergoing with drives operating in plain USB mass > storage class. In a first time, I'm filling drives with data > (uncontrolled corpus, just TBs that I have on hand). It looks like the > drives with most usage history are the ones that drop most often. > > kernel: usb 3-4.1.1: reset SuperSpeed USB device number 6 using > xhci_hcd kernel: usb 3-4.2.1: reset SuperSpeed USB device number 7 > using xhci_hcd kernel: usb 3-4.3.1.1: reset SuperSpeed USB device > number 13 using xhci_hcd kernel: usb 3-4.3.2.1: reset SuperSpeed USB > device number 14 using xhci_hcd kernel: usb 3-4.4: reset SuperSpeed > USB device number 8 using xhci_hcd kernel: usb 6-4.3.2.1: reset > SuperSpeed USB device number 8 using xhci_hcd kernel: usb 6-4.3.3.1: > reset SuperSpeed USB device number 9 using xhci_hcd kernel: usb > 6-4.4.1: reset SuperSpeed USB device number 6 using xhci_hcd > > Will provide some more interesting/visual data later. > > > I'm surprised that the message "reset SuperSpeed USB device ..." is > displayed without prior information about why. > Someone with more background could give hints? > > > I took a look at the USB MSC code and have few questions / > observations: > > - It looks like (haven't tested it yet) the CONFIG_DYNAMIC_DEBUG isn't > used with the USB mass storage debugging infrastructure, please > confirm? If unused, are we interested to have a patch that would go > back to regular pr_debug() that can work with dynamic debugging? > > Because with several of these drives / lots of activity / occasional > issues, it looks like it will be hard to catch (yes I can use > usbmon). > > - It looks like there is no configurable timeout for USB MSC requests. > Perhaps the device is not responding in time and this is why it's > reset? > > > Best regards,
