On Mon, 1 Oct 2012, Sarah Sharp wrote: > > > Maybe the link > > > becomes unstable when LPM is enabled, and that causes transfer issues on > > > the beginning of some transfers? > > > > Maybe so. It's odd that the problem seems to affect only control > > transfers. All the bulk transfers in the usbmon trace went through > > properly. > > Hmm, that is interesting. Hard to know what it means, though. Maybe the bus trace will provide a clue. > Looking at the LPM handling, I have a couple hypothesis about what might > have happened. > > First, I'm wondering if we're not waiting until the device exits U1/U2 > before issuing the reset. If a device has a long U1/U2 exit latency, > then we'll hit it with the reset before it comes out of U1/U2. Don's > device started acting up after it was reset, so that might explain his > issues. Actually the device starting acting up _before_ it was reset. It was this misbehavior that caused usb-storage to issue the reset in the first place. Then after the reset, everything became much worse. > Second, I'm wondering if LPM is interacting with system suspend and > resume in a bad way. I noticed in my log with the USB 3.0 hub and hard > drive that LPM was disabled for the hub before the system went into > suspend, but LPM was not disabled for the hard drive. We should have > disabled LPM if usb_port_suspend() was called for the hard drive's port. > I'll have to add some more debugging to see if it was called, but I > don't think it is. > > ISTR that you said when the system is suspended or hibernated, only the > roothub ports are placed into suspend, because the rest of the bus will > be placed into global suspend when the system goes into S3/S4. I said that only the root hub's ports _need_ to be suspended. And of course, that statement doesn't apply to USB-3 ports. > However, > there is no link state transition between U1/U2 into U3. If a USB 3.0 > device in the second tier of the tree is in U1/U2 when the system is > suspended, we're attempting to put it into U3 from U1 or U2. That could > possibly cause us to hit bugs in the device firmware, since we're > forcing the device through an undefined link state transition. I don't remember the details. Doesn't usb_unlocked_disable_lpm() force the device back into U0? You call that routine before suspending the port. > Is my recollection of the system suspend procedure correct, or do I have > something wrong here? Currently we do suspend all the attached devices when going into system suspend. But we don't when going into the FREEZE or PRETHAW stages of hibernation -- all we do is call the bus_suspend routines for root hubs. That may need to be changed for USB-3 buses. 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
