On Mon, 2 Sep 2013, Bjørn Mork wrote: > 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. Here's something that might be relevant from the USB-2.0 spec (section 9.2.6.4): For standard device requests that require data stage transfer to the host, the device must be able to return the first data packet to the host within 500 ms of receipt of the request. For subsequent data packets, if any, the device must be able to return them within 500 ms of successful completion of the transmission of the previous packet. The device must then be able to successfully complete the status stage within 50 ms after returning the last data packet. The initial Get-Device-Descriptor request (the 64-byte version) requires only one data packet from the device, except for low-speed devices, which require 3 packets. Therefore the initial_descriptor_timeout value could in principle be set to 600 ms (1600 for low speed). You can experiment with this value easily, because it is a module parameter. Also, the inner loop of 3 probably doesn't do any good. The middle loop should accomplish basically the same thing. > 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. Just remember that some devices may take longer than the specified time to recover from suspend. 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
