Re: 2.5.69 Interrupt Latency

Alan Stern (stern@rowland.harvard.edu)
Tue, 13 May 2003 17:35:47 -0400 (EDT)


On Tue, 13 May 2003, Greg KH wrote:

> On Tue, May 13, 2003 at 11:09:13AM -0700, Greg KH wrote:
> > On Tue, May 13, 2003 at 08:01:01AM -0500, Paul Fulghum wrote:
> > >
> > > I applied the patch plus a couple of printk statements,
> > > and the wakeup_hc() is being continuously called
> > > as well as actually executing the delay.
> >
> > Is the suspend_hc() function ever getting called by anyone in that
> > driver?
>
> Ok, nevermind, I see where it would be getting called under normal
> operation...
>
> Hm, I don't really know. Johannes, any thoughts?

My take is that wakeup_hc() is getting called whenever some stray signal
causes the device to generate an interrupt, and then a little while later
the stall timer routine calls suspend_hc() since nothing is active. The
interrupts are probably indistinguishable from what you would get if a new
device really had just been attached to the bus.

Assuming this analysis is correct, only malfunctioning hardware would ever
cause the problem to arise. Still, it's something that needs to be
handled. (That's a tricky point -- to what extent should the kernel try
to compensate for broken hardware?)

Unfortunately, there isn't any obvious way to tell that under these
circumstances the wakeup_hc() routine doesn't need to run. Using a timer
routine to implement that 20 ms delay would at least remove the large
interrupt latency. However, this presents some problems as well. In
particular, is there anything that would prevent suspend_hc() from being
called before the timer had expired? We don't want to find ourselves
simultaneously trying to turn the USB controller on and off. Getting that
done properly will require some thought.

Maybe a kind of grace period would help: each time the controller changes
state, don't allow another change until at least 1 second later. That
would also help the "bouncing" effect I see when I turn on or off my USB
CD-RW drive.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/