What happens when you disable interrupts, and what do you do with interrupts you don't know how to handle?

10
votes

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"?

2
assemblyx86interruptinterrupt-handlingisr
"Message" is the wrong mental image, it is just a signal. CLI tells the processor to ignore it. The device doesn't do anything while it waits for the interrupt handler to start transferring data and thus reset the request. There is no scenario where you cannot know how to handle the interrupt, you wouldn't have programmed the PIC to enable the IRQ. – Hans Passant
@HansPassant: Ah I see, thanks! – user541686

2 Answers

7
votes

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.

4
votes

The interrupts still fire, but the CPU isn't listening. When you start listening again (sti), the signal is still there and will take effect at the first opportunity.

A PC PIC has several levels of interrupts, and I believe it can hold one active interrupt for each priority level. It will keep each one of them until the CPU tells it that the corresponding handling is completed. Having interrupts disabled for an extended period of time will probably break this, so just don't do that!

The device responsible for an interrupt will not get any response while waiting - which is kind of a response anyway. If it can't wait, it might enter some error state that the CPU will see when it eventually comes around.

You will only get the interrupts you have explicitly enabled, so there should be no surprises. The device driver turning on an interrupt has better know how to handle it.