Re: [ath9k-devel] ath9k: massive unexplained latency in 2.6.27 (rc5,rc6, probably others)

[Steven Noonan]

On Fri, 19 Sep 2008, Robert Hancock wrote:

> Steven Noonan wrote:
> > Second of all, I'm looking at the ath9k interrupt handler right now,
> > and there are a few cases where it returns IRQ_NONE. And here's where
> > I'm a bit fuzzy. Since there could be any number of things using IRQ
> > 17 (though in my case, ath9k is on its own dedicated IRQ), it seems
> > odd that you check the value of sc->sc_invalid, since the cookie
> > passed to the handler might not actually be ath9k's cookie if multiple
> > drivers have registered IRQ handlers for that particular IRQ. Who
> > knows if what you're reading is even valid? Heck, what if some driver
> > uses a NULL for their cookie (however unlikely)? You'd get a
> > segmentation fault on the second line of the interrupt handler. Of
> > course, I could be completely wrong: does parent interrupt handler
> > check to see which device driver owns the particular device signaling
> > an IRQ and then call the appropriate handler?
> 
> All the IRQ handlers registered on that interrupt will get called. The cookie
> will always be the right one for that handler however.

Thank you! I appreciate the explanation.

> The bug is presumably that it returns IRQ_NONE in some cases where the device
> is actually generating an interrupt. The advice to turn on irqpoll is rather
> useless in this case - that's mainly useful where the IRQ routing is messed up
> and the device can't receive any interrupts at all.

Strange, though, that irqpoll solved the connectivity issues (but of 
course created the ridiculous latency that this thread's all about).

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