RE: Understanding Interrupts

["Naidu, Venkata" <Venkata.Naidu@xxxxxxxxxxx>]

-> 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/