Weekly Edition
Return to the Kernel page
| |||||||||||||
An interrupt handling change
One problem that can confront an operating system kernel is that of
"screaming" devices - hardware which continually raises interrupts, but for
which there is no driver to tell it to shut up. If the offending hardware
is yanking on an interrupt line which is not otherwise in use, the kernel
can quickly disable that line and be done with the problem. If, however,
the interrupt line is in use in a shared mode, there is (in kernels through
2.5.68) no way for the kernel to know that nobody is dealing with the loud
device. All it can do is pass an interrupt request to the registered
handlers and hope for the best.
Of course, there is no need for things to be that way; each device driver knows whether it handled a specific interrupt or not. So all that's needed is for the drivers to communicate that information back to the kernel. The 2.5.69 kernel does exactly that - thanks to a patch by Linus - at the cost of breaking every driver which registers an interrupt handler. Interrupt handlers no longer return void; instead, they must return an irqreturn_t value (adding typedefs to the kernel is OK when Linus does it). The values are IRQ_HANDLED if the driver recognized the interrupt or IRQ_NONE if the interrupt was not for one of the driver's devices. The IRQ_RETVAL(handled) macro can also be used; the handled parameter should be nonzero if the interrupt was handled in the driver. With this change, the kernel can tell whether a particular device is being handled or not. As of this writing, the "fix the drivers" effort is in full swing; by the time 2.5.69 is released, most of the (in-tree) drivers should be working again. At least, with regard to the interrupt change. (Log in to post comments)
An interrupt handling change Posted Apr 24, 2003 2:51 UTC (Thu) by tony_peden (guest, #531) [Link] I'm certain it's a product of my ignorance of such low-level details, but what can the kernel do once it knows an interrupt wasn't handled?
An interrupt handling change Posted Apr 24, 2003 3:00 UTC (Thu) by proski (subscriber, #104) [Link] I think it's possible to reroute interrupts from the suspected device using APIC. However, I don't see any such code in the kernel yet. Perhaps the API change was done in preparation for futher changes that would affect less code.
Culprit for Firewire Build Failures, Perhaps. Posted Apr 24, 2003 7:54 UTC (Thu) by AnswerGuy (guest, #1256) [Link] This might explain why my 2.5.68 compiles were failing on any attempt to add firewire (ieee1394) support.
Culprit for Firewire Build Failures, Perhaps. Posted Apr 24, 2003 12:22 UTC (Thu) by proski (subscriber, #104) [Link] The patch first appeared later, in 2.5.68-bk2, so your guess is wrong.
An interrupt handling change Posted Apr 24, 2003 14:36 UTC (Thu) by cjdewey (guest, #5128) [Link] There's more context for this change on the dri-devel mailing list. Linus has apparently been trying to get his Radeon card to work. ;-)http://sourceforge.net/mailarchive/forum.php?thread_id=2005408&forum_id=7177
|
|||||||||||||