On Mon, 4 Oct 2004 15:41:11 -0400, Naidu, Venkata <venkata.naidu@xxxxxxxxxxx> wrote: > Interrupts can be masked (i.e., temporarily disabled) in three > main places: > 1. by setting appropriate registers in PIC or > 2. by setting appropriate registers in the CPU or > 3. by setting appropriate device specific registers > > Disabling interrupts in the device is not a common practice. However it is common practice to re-enable interrupts in a device following an interrupt. Most devices have some control register with a bit which must be reset in a handler. > Linux actually masks the interrupts, in both PIC and CPU. It masks out the interrupt which came in from a particular IRQ line on the PIC. It masks out the entire PIC routing to the local CPU (by disabling a CPU control register bit such as the MSR EE external exceptions bit on ppc) while it's figuring out what to do with with the right interrupt handler. > Because disabling an interrupt on a CPU is different from > disabling an interrupt on an entire system. That's nice and vague. > Note that PIC(s) sits between devices and CPU(s). With stuff like APIC, routing between devices and CPUs is software controllable to an extent (although I have almost nothing to do with APIC at all). > As long the as the interrupt status registers are not cleared, > PIC keeps sending the interrupt to CPU. Nah. Depends upon the hardware and the nature of the interrupt. Level sensitive (when a line goes high or low in relation to a reference - e.g. ground - base voltage) CPU interrupts will remain high until acknowledged whereas edge (a transition in voltage which might be either rising or falling) triggered ones will simply by fire and forget. This is all taken care of it special logic within the CPU which effectively checks the INT (or equivalent) pin on each processor cycle. > If an interrupt line is masked at the PIC, then PIC won't > trigger the CPU. If CPU acknowledges the interrupt before > handling the interrupt, then that interrupt can be lost, > but not always. As long as the CPU calls a handler then there is no problem. There is a problem when an acknowledgement is sent to the PIC and the device does not fire another. > Because, some devices maintain local buffers and registers and require > acknowledgement after processing the interrupt. That's entirely different again. That's down to programming a device control register to say "ok I got that" and "you can go ahead and generate another when you're ready". As I mentioned above. > So, the answer to your question (losing and interrupt) is > very specific to device and where/how you mask the interrupt, > PIC or CPU. Losing an interrupt is very rare these days. Depends upon the hardware. If you're using level triggered interrupts then it's very difficult to lose an interrupt because the IRQ line in to the PIC will remain high until you've taken care of all interrupts which are being generated on it. > That said, RTC still drifts sometime (in high interrupt > load). Wrong nomenclature. > But, Linux kernel maintains previous time stamp > and updates RTC accordingly using jiffies etc. It does check to see if a timer tick was missed and attempts to compensate for that. > http://billgatliff.com/articles/emb-linux/interrupts.pdf Useful. Jon. -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
