-> Thanks for the help!
-> I did understand most of it, just a little unsure on the
-> last thing you said.
->
-> > Yes, by disabling an interrupt, interrupt controller or
-> > processor doesn't invoke kernel IRQ for that interrupt.
-> > The main job is performed by interrupt controller and
-> > not the processor. But, that interrupt is not lost. Once
-> > an interrupt is enabled, kernel gets the IRQ.
->
-> I hope I got this right. You mean to disable an interrupt by
-> masking it out in the interrupt controller, and not with cli?
-> Since this will program the controller, and not the CPU as
-> you said.
->
-> If there are more than one interrupt occurring on the same
-> IRQ line, will the processor receive all those interrupts when
-> they are enabled, or just the last.
-> For example, if I disable the timer IRQ and later enable it.
-> Will the CPU get all those missed timer interrupts, or just
-> the last one?
->
-> Is this true for clearing IF with cli as well? that the interrupt
-> will not be lost?
Since you asked more, let me try to explain.
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.
Linux actually masks the interrupts, in both PIC and CPU.
Because disabling an interrupt on a CPU is different from
disabling an interrupt on an entire system.
Note that PIC(s) sits between devices and CPU(s). The
communication between PIC and CPU is little reliable. That
means, if PIC sends an interrupt to CPU, CPU acknowledges
the interrupts. As long the as the interrupt status
registers are not cleared, PIC keeps sending the interrupt
to CPU.
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. Because, some devices maintain local
buffers and registers and require acknowledgement after
processing the interrupt. As long as the data is available
in the local buffers, devices keep sending interrupts to
PIC (for example, NIC devices).
If interrupts are disabled at PIC registers, then only the
latest interrupt is delivered after the interrupt is enabled.
There is no counter maintained for every pin. All that PIC
maintains is a single bit per pin/device.
The communication between PICs and CPUs is very complicated
in SMP environment where APICs (advanced programmable
interrupt controllers) distribute/load-share interrupts
between multiple CPUs and CPU-to-CPU interrupts etc etc.
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.
That said, RTC still drifts sometime (in high interrupt
load). But, Linux kernel maintains previous time stamp
and updates RTC accordingly using jiffies etc.
FYI-
http://billgatliff.com/articles/emb-linux/interrupts.pdf
Venkata.
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
