On Wed, 15 Nov 2017, Jérôme Carretero wrote: > (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? usb-storage resets a drive whenever the SCSI layer tells it to or when a protocol error occurs. As far as I know, the SCSI layer issues these resets only when a command has timed out. > > 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? dev_dbg() please, not pr_debug(). But yes, that would be worthwhile. Note, however, that usb-storage debugging is meant only for debugging problems in the usb-storage driver itself, not for debugging problems in attached devices. We use usbmon or wireshark for the latter. > > 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? Timeouts are set by the SCSI layer. I believe they are rather long (30 seconds, by default). Presumably they are configurable, although I would have to do some digging to figure out how. Alan Stern
