When you disable interrupts (with the cli
instruction in x86), what exactly happens?
Does the PIC wait for you to turn on interrupts, and fire the interrupt when that happens? (If so, how long does it wait, and what happens if the time 'expires'?)
Does the interrupt -- from the device's perspective -- get sent into a "black hole", with no response?
Does the PIC somehow tell the device that "the CPU is busy" or something?
Or does something else happen?
Also, how do you deal with an interrupt you don't know how to handle?
Is there some way to tell the PIC (or the device, if you don't know what the device is), "yes, I got your message, but I don't know what to do with it"?
There are kernels which don't disable interrupts in interrupt handler and has interrupt stack and allows low priority interrupts to be interrupted by high priority interrupts.
If an interrupt comes in in-between any of those instructions and modifies the data, your first ISR can potentially read the wrong value. So you need to disable interrupts before you operate on it and also declare the variable volatile .
When an interrupt occurs, it causes the CPU to stop executing the current program. The control then passes to a special piece of code called an Interrupt Handler or Interrupt Service Routine. The interrupt handler will process the interrupt and resume the interrupted program.
The 8259a PIC waits for the INTA signal from the CPU. The CPU sends it when starts handling the interrupt by transferring the control to the appropriate ISR. Which ISR? The PIC gives the interrupt vector to the CPU, which looks up the IVT/IDT for the address and you know the rest. The PIC won't supply the interrupt vector until it receives INTA.
The 8259a PIC has only one-way communication with I/O devices. They can tell it that they have an interrupt that needs servicing.
So, everything's up in the air in the PIC if the CPU does not respond to interrupts. However, devices may at their whim de-assert and then re-assert interrupt request signals. I don't know which do. I also don't know which have any time requirements for interrupt servicing.
If you're not interested in interrupts from a specific source, you can just mask it and you won't get any. If you take an interrupt but don't know how to process it, you can just tell the PIC you've handled it. This may leave the interrupted device in a "frozen" state, waiting indefinitely for servicing to happen. It may also cause the device to keep its interrupt request signal high, which will be a problem if you're taking interrupts in level-triggered mode -- you'll be continuously getting interrupts.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With