Re: [PATCH] msleep() with hrtimers

On Thursday 09 August 2007, Andrew Morton wrote:
> On Fri, 03 Aug 2007 12:37:12 -0600 Jonathan Corbet <[email protected]> wrote:
> 
> > Here's the second (and probably final) posting of the msleep() with
> > hrtimers patch.  The problem being addressed here is that the current
> > msleep() will stop for a minimum of two jiffies, meaning that, on a
> > HZ=100 system, msleep(1) delays for for about 20ms.  In a driver with
> > one such delay for each of 150 or so register setting operations, the
> > extra time adds up to a few seconds.
> > 
> > This patch addresses the situation by using hrtimers.  On tickless
> > systems with working timers, msleep(1) now sleeps for 1ms, even with
> > HZ=100.

For what it's worth, I've been using this on a variety of systems since
August, without even one observed problem.  I rather like the idea of
an msleep() that really does what it claims to do, instead of wasting
extra time!


> >			...
> 
> This failed the Vaio test.  I guess it triggered a USB bug.

Does it still fail?


> With this patch applied, when I hotplug my wireless mouse, the little LED
> on the mouse comes on for a second or so then goes out and no pointy clicky
> for me.
> 
> It says:
> 
> [  152.481522] usb 1-1: new low speed USB device using uhci_hcd and address 2
> 
> 
> Without this patch applied, I get
> 
> [  195.935445] usb 2-1: new low speed USB device using uhci_hcd and address 2
> [  196.116183] usb 2-1: configuration #1 chosen from 1 choice
> [  196.198362] input: Microsoft Microsoft Wireless Optical Mouse 1.00 as /class/input/input7
> i		...
> 
> and lots of pointy clickiness.

In short, the enumeration of this device broke.  That's all handled
by khubd in usbcore.  But without enabing USB_DEBUG we can't very
well know *how* it broke.

Now one reason this failure is interesting is that there are other
cases with mysterious enumeration failures ... often involving EHCI
for some reason.  And my brain couples many of these to bugfixes we
made in the enumeration logic a long time ago, which involved changing
timings (and some other stuff).  We started to get a lot more reports
about such failures about a release after those fixes...

Which makes me suspect that once this particular enumeration timing
problem got fixed, some other stuff might behave better too.  And if
it didn't behave better, then we'd at least have a better handle on
which enumeration delays seem to trigger problematic device behavior.


> I would assume that there is some msleep() in USB which is too short, and
> the present wild rounding-up which msleep() does covered up the
> incorrectly-chosen sleep duration.
> 
> I'm using HZ=250 (http://userweb.kernel.org/~akpm/config-sony.txt) and it
> could well be that the mouse would fail just by going to HZ=1000, but I
> didn't bother testing that.
> 
> Could one of the USB developers please suggest which msleep()(s) I should
> start looking at?

If there was followup to the "what do the logs show with CONFIG_USB_DEBUG"
response, I didn't see it.

- Dave


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel