On Tue, 26 Feb 2008, Jan Gutter wrote:
> > 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))) {
> > > >
> > >
> > > 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.
>
> 2000ms fails, but 3000ms succeeds. Keep in mind, though, that I did not
> suffer any of these problems in 2.6.23. How the heck did it manage to
> work there? Hub not shutting down for powersave, other init mechanism,
> something like that?
Nothing I can think of along any of those lines would make any
difference.
> > Maybe we should add some sort of exponential backoff to the delay time
> > between the reset and the first Get-Descriptor request.
>
> Hmmm, it would be interesting to chart the state diagram and cater for
> all the broken hardware. I'm worried that this would cause some *other*
> broken things to break in new and interesting ways...
So far your device is the only one I've heard of with this problem.
> > 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.
>
> I agree, but again, 2.6.23 == fun, 2.6.24 == no fun. Windows XP and
> Vista (yeah right!) have no problems either. Even a single-chip DVD
> player with USB-in has no problem (dunno if it uses USB2 or USB1.1,
> though). Counterargument: this seems to be the only USB-device
> regression in 2.6.24, if it were some weird timing issue in the USB
> stack, the fallout *should* have been easily visible!
>
> You think it's time to work on an instrumented 2.6.23 and compare the
> code paths taken to those in 2.6.24?
No need, at least not yet. You can get high-precision timing values
from usbmon. See Documentation/usb/usbmon.txt.
If that doesn't show anything useful, my next suggestion is bisection.
You're lucky that the problem is quickly and reliably reproducible.
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
