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-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
