Please use Reply-To-All so that the mailing list can see your
responses.
On Tue, 26 Feb 2008, Jan Gutter wrote:
> On Mon, 2008-02-25 at 11:10 -0500, Alan Stern wrote:
>
> > You can try adding an explicit delay to see if it helps. In
> > drivers/usb/core/hub.c:hub_port_init(), add a call to msleep just
> > before the line:
> >
> > for (i = 0; i < GET_DESCRIPTOR_TRIES; (++i, msleep(100))) {
> >
> > I don't know how large an argument to msleep you'll need. 100? 5000?
> > Note that there's already a 50-ms delay before the loop begins.
>
> Ok, in desperation I tried 5000ms, and it worked. 2000ms is still not
> enough though. I'm "bisecting" the time now to try to find out what the
> minimum time is.
>
> I think you're right, it seems unlikely that a couple of spinlocks would
> cause this much delay.
>
> Just for the heck of it, I also reverted the EREMOTEIO optimization that
> was in the same patch -> no change, as expected. (The "Centralize
> EREMOTEIO" patch that preceded it should nullify the logic anyway...)
Maybe we should add some sort of exponential backoff to the delay time
between the reset and the first Get-Descriptor request.
Still, if a device takes more than 2 seconds to initialize itself
after a reset, what do you expect? According to the USB spec, it
shouldn't take more than 10 ms.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
