7

What happens to interrupts that are sent to the processor after i use cli command and before i use sti to enable them again?

yonigo
  • 987
  • 1
  • 15
  • 30
  • 1
    "Lost interrupts" are lost forever. There is no "Recycle bin" to recover them from. – TheCodeArtist Mar 16 '14 at 15:56
  • So just to be sure: If the processor gets an interrupt from a device (say i NIC) after i used cli, the interrupt will be lost forever? How does the NIC know the interrupt is lost and what does it normally do in this case? – yonigo Mar 16 '14 at 15:59
  • 1
    Depending upon how the peripheral device (a NIC for example) is configured, it will wait for the CPU to acknowledge. After a pre-configured time during which the CPU(with interrupts disabled) does NOT respond, the peripheral may retry sending another interrupt. Alternately it could simply give-up. – TheCodeArtist Mar 16 '14 at 16:08
  • An interrupt will not be lost unless you specifically clear one during a CLI "period". CLI will just delay the interrupt response until STI (+1 more instruction, used to allow STI / RETI sequence) is issued. – rcgldr Mar 16 '14 at 20:18
  • 1
    OK now I'm confused, your both saying different things, Can one of you get me to some documentation reference? – yonigo Mar 16 '14 at 21:24
  • Intterupts aren't "lost" by using CLI. Operating systems count on this since they use CLI to protect small critical code sections from interrupts. When the STI (+1 instruction) is issued, then any pendnig interrupts that occurred since the CLI will then get processed. Level driven interrupts would never be an issue, and any input for an edge driven interrupt will hold an internal level until that specific interrupt is cleared (CLI does not do this). – rcgldr Mar 16 '14 at 23:06
  • One issue could be a periodic interrupt, such as a timer that triggered every 1 millisecond, and having interrupts disabled for more than 1 millisecond, in which case a interrupt would be "missed". – rcgldr Mar 16 '14 at 23:37
  • @yonigo while i focussed on the cases where the interrupts are likely to be lost, rcgldr has pointed out a couple of scenarios where they can still be handle gracefully after enabling interrupts. However as he rightly pointed out, this cannot be always guaranteed. Checkout this [**answer**](http://stackoverflow.com/a/10673452/319204) for a details on how the result is often implementation specific. Also a brief explanation of [**cli/sti** are deprecated on modern operating systems](http://www.xml.com/ldd/chapter/book/ch09.html#t1). – TheCodeArtist Mar 17 '14 at 09:17

1 Answers1

7

As several people in your comments have said, interrupts do not get lost. The interrupt that has happened between the CLI and STI gets serviced as soon as you re-enable the interrupts using the STI instruction.

To understand the behaviour, you must know, how interrupts are delivered to the processor. To quote Intel Developer Manual:

Asserting the INTR pin signals the processor that an external interrupt has occurred. The processor reads from the system bus the interrupt vector number provided by an external interrupt controller, such as an 8259A

The key is that INTR pin is asserted by the 8259A PIC until you, in the interrupt service routine, acknowladge the interrupt. Thus, when you disable interrupts, you are just instructing the processor to ignore the INTR pin. When you re-enable the interrupts, you stop ignoring the INTR pin and processor starts handling the interrupt right away.

Disclaimer: this is a legacy behaviour, but sufficient for explanation.

rkapl
  • 972
  • 6
  • 13