On Wed, 23 Jan 2013, Ming Lei wrote: > On Wed, Jan 23, 2013 at 4:08 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > Lei: > > > > It turns out that your patch setting the autosuspend delay for hubs to > > 0 causes problems for root hubs. They need a delay of at least 30 ms. > > > > When a child device sends a remote wakeup request, the root hub > > generates an interrupt. The HCD's interrupt handler sees what happened > > and requests a runtime resume for the root hub. However it can't tell > > the hub driver about the wakeup request until the port resume is > > finished, which takes about 25 ms. During that time, the hub driver > > won't know what has happened and so it will try to autosuspend. The > > autosuspend will fail because the port is resuming, but the hub driver > > will go right ahead and keep trying to autosuspend. This will continue > > until the port resume is complete. > > > > In order to avoid all these extra autosuspend attempts, the delay > > for root hubs should be set to something larger than 25 ms, such as 30 > > ms. Do you agree? > > IMO, that should be the simplest fix on the problem. > > But, looks the delay of 25ms or 30ms is only required in the above > remote wakeup case, and user can override the delay too, so maybe > we need to figure out one better approach to deal with that. Other strange things seem to be happening. Take a look at the log just posted by Norbert Preining: http://www.preining.info/usb-syslog-prob.txt Starting at timestamp 400.570029, the external hub and root hub go into a strange remote wakeup loop. I don't know why; maybe some external program is trying to access the external hub over and over again. This continues for more than 10 seconds! If the delay were set to 30 ms, the amount of activity would be greatly reduced. > Could we add a delay in hub_events() for handling the case? see below > draft patch for explaining the idea: Yeah, we could improve the situation. But until we know what's happening with Norbert's machine, my feeling is that a short delay would be better. 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
