Really no more interrupts until "end-of-interrupt" code?

[Craze Frog]

Before the ret, this code is executed, to tell the PIC that it's OK to send any new or pending interrupts, because the current one is done. The PIC doesn't send any more interrupts until the cpu acknowledges the interrupt:

Is that really true even if sti is executed?

[cyr1x]

It is.

[01000101]

If you don't ACK the PIC, it will assume that you're still handling that interrupt and not allow any more interrupts for that vector.

[Craze Frog]

If you don't ACK the PIC, it will assume that you're still handling that interrupt and not allow any more interrupts for that vector.

Ah, so it wasn't really true. Thanks for clarifying this, someone should fix the wiki.

[01000101]

POC: enable IRQ 0 (PIT) and IRQ 1 (keyboard) and instead of sending an EOI after the keyboard handler, just put a sti() and a for(;;); loop... once you hit a key and IRQ 1 fires, it won't again. But the handler for IRQ 0 will still be getting interrupts even after the keyboard IRQ 1 has halted.

[Brendan]

Hi,

To be as accurate as possible:

If you don't send an EOI to the PIC, and if the PIC is in it's normal operating mode (e.g. not some strange mode, like "auto-EOI" or "rotating priority"), then you won't get any more interrupts for that IRQ or any other lower priority IRQs.

Also note, the PIC's priorities go in this order:

• irq0 <- highest priority
  irq1
  irq8
  irq9
  irq10
  irq11
  irq12
  irq13
  irq14
  irq15
  irq3
  irq4
  irq5
  irq6
  irq7 <- lowest priority

There's also the whole "spurious IRQ" mess - IMHO spurious IRQ7 and spurious IRQ15 are higher priority than IRQ0, but you should never send an EOI for spurious IRQs.


Cheers,

Brendan