On 5/24/06, Erik Scharwaechter <diozaka@xxxxxx> wrote:
Hello, in some situations, the Linux kernel may disable interrupts using local_irq_disable(). On x86 systems this is implemented with the CLI assembly instruction, which sets the CPU's IF flag to 0. The IA32 System Programming Guide says about clearing the IF flag: > When the IF flag is clear, the processor inhibits interrupts delivered to > the INTR pin or through the local APIC from generating an internal > interrupt request. As far as I understand this passage, interrupts delivered to the processor are disposed and not put into some kind of internal queue. What if an important interrupt, i.e. an interrupt that has to be handled as soon as possible, is sent to the processor while the IF flag is set to 0? The kernel will never notice this event, unless the interrupt is resent again later by the device. Is this correct?
When IF flag is set to 0, IPC do send the interrupt signals to CPU on INTR pin but CPU simply do not honour them. Unless and untill CPU does not honour and acknowledge back the interrupt to IPC, IPC does keep note of interrupt as pending. When IF flag is set to 1 again, then these pending interrupts are handled. Read more on this: http://lkdp.blogspot.com/2006/01/interrupt-handling-internals-in-linux_22.html regards, Gaurav
Wouldn't it be more efficient to add the missed interrupts to a queue to deal with it as soon as interrupts have been enabled again? Regards, Erik -- Erik Scharwaechter http://diozaka.org GPG: 0x42B654AB -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
-- Gaurav Email: gauravd.chd@xxxxxxxxx -------------------------------------------- Read my Linux Kernel blog at: http://lkdp.blogspot.com/ -------------------------------------------- -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
