Am Dienstag, 27. Februar 2007 17:03 schrieb Alan Stern:
> On Tue, 27 Feb 2007, Oliver Neukum wrote:
>
> > Hi,
> >
> > flaky hardware can cause a lot of debounce failed messages. To limit
> > the performance impact, a ratelimit should be used.
>
> Oliver, I've noticed in the past that khubd tries too hard to enumerate a
> new connection. The new scheme and the old scheme are both tried twice,
> and each try has two attempts to read the device descriptor, where each
> attempt can loop twice, each loop with up to three calls to
> usb_control_msg() and a device reset, with timeouts as long as 1 second.
>
> In really bad cases this can tie things up for close to a minute. We
> ought to be able to do better. Some of the loops should be eliminated and
> some of the timeouts decreased.
>
> Would you like to take a close look at it?
You want me to do the deed where somebody _will_ be screwed no matter
what? ;-)
IMHO there's nothing wrong with trying hard to enumerate a device.
In particular we cannot shorten timeouts beyond what the spec says. In
fact it is very advisable to be generous.
So it would seem to me that in the general case the effort should not
be reduced. However how about a per port flag to be set if enumeration fails?
If that is set the port would get only the short version.
This way a flaky device might work, but a flaky port or cable would not
hold up the system more than once.
What do you think?
Regards
Oliver
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
