Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > On Sun, 1 Sep 2013, Bjørn Mork wrote: > >> Sep 1 12:32:39 nemi kernel: [174042.120072] usb 1-6: device descriptor read/64, error -110 >> Sep 1 12:32:39 nemi kernel: [174057.336066] usb 1-6: device descriptor read/64, error -110 >> Sep 1 12:32:39 nemi kernel: [174057.552069] usb 1-6: reset high-speed USB device number 11 using ehci-pci >> Sep 1 12:32:39 nemi kernel: [174072.664067] usb 1-6: device descriptor read/64, error -110 >> Sep 1 12:32:39 nemi kernel: [174087.880154] usb 1-6: device descriptor read/64, error -110 >> Sep 1 12:32:39 nemi kernel: [174088.096131] usb 1-6: reset high-speed USB device number 11 using ehci-pci >> Sep 1 12:32:39 nemi kernel: [174093.116266] usb 1-6: device descriptor read/8, error -110 >> Sep 1 12:32:39 nemi kernel: [174098.236333] usb 1-6: device descriptor read/8, error -110 >> Sep 1 12:32:39 nemi kernel: [174098.452066] usb 1-6: reset high-speed USB device number 11 using ehci-pci >> Sep 1 12:32:39 nemi kernel: [174103.472272] usb 1-6: device descriptor read/8, error -110 >> Sep 1 12:32:39 nemi kernel: [174108.592328] usb 1-6: device descriptor read/8, error -110 >> Sep 1 12:32:39 nemi kernel: [174108.808090] usb 4-2: reset full-speed USB device number 2 using uhci_hcd >> Sep 1 12:32:39 nemi kernel: [174109.052051] usb 7-1: reset full-speed USB device number 2 using uhci_hcd >> Sep 1 12:32:39 nemi kernel: [174109.204966] PM: resume of devices complete after 82555.697 msecs >> >> As you can see from the last line, resuming devices takes ridiculously >> long time. Normally it would take approximately on second on this old >> laptop. > > This is a problem we have known about for many years, but nobody has > complained loudly enough for any changes to be made. When initializing > or resetting a device, the USB core tries too hard and takes too long. > It uses two different initialization algorithms, with various nested > retry loops and long timeouts. If you want to look through the code > and try making your own changes, the guilty parties are hub_port_init() > and hub_port_connect_change() (which calls hub_port_init in a loop) in > drivers/usb/core/hub.c. Thanks for the pointer. I see that there are quite a number of attempts (2 * 2 * 4) to read the device descriptor using the default 5 second control message timeout, which accounts for most of the 82.5 second delay. The number of repetitions of a command having such a long timeout in the first place seems excessive to me. But the code is old, and I guess it was put there for a reason... And reducing it to any number > 1 still end up with a much too long delay IMHO, so there is no point in trying to reduce the number of iterations. > Normally this doesn't matter, because it happens more or less > transparently in the background. But during system resume it can be > annoying, and during system suspend it can result in a freezer timeout > and failure to suspend. Yes. I don't want to wait even a single 5 second timeout during resume. It's just too long for any device. Either the device is immediately available or it failed to resume and needs to be dealt with as a disconnect + connect. I'll see if I can find out how to fail much much faster during resume. OK, I realize there will be all sorts of considerations of root file system on USB storage, or NFS over USB network, or... IMHO, there is no reason to believe repeated attempts with long delays are going to solve anything. If your disk failed to resume then it failed. Bjørn -- 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
