On Wed, Aug 17, 2011 at 4:47 PM, Joel A Fernandes agnel.joel@gmail.com wrote:
Hi Simon,
Thanks a lot for reviewing the issue.
With respect to using a bulk USB stick (some of which take 3s or more to respond to a submit) this doesn't make any difference for me. It seems to take a long time to respond the first time, so the 5s timeout seems prudent.
Since this sorts out the network side we can probably skip that patch.
Are you suggesting we revert the patch you had submitted [2], instead of deleting the goto line as done in my patch? I think it would be better if we left [2] in and allowed the async disable to happen after a timeout like I'm doing.
There are other patches that are reported to fix the issue such as [3] and [4], but I think they are more like workarounds and delay the occurrence of the event of a timeout itself. A timeout which would occur for any other reason such as too many USB devices connected to the hub can trigger the problem, and, not running async schedule and the other code after the timeout seems to make EHCI unrecoverable.
My feeling was that the time was more a function of the device that is plugged in than the USB port/peripheral. Perhaps someone will find a device which needs a 10s timeout, so I agree just increasing it is not really the solution.
I found that once the device timed out it needed a reset to work - just resubmitting the urb didn't work for me. Maybe I had some other problem.
Anyway I think your patch looks good, thank you.
Could I add your Acked-by to the submission as well?
Hi Joel,
Yes.
Acked-by: Simon Glass sglass@chromium.org
Regards, Simon
thanks,
Joel