When is the bit in IRR of 8259 cleared?

[crasher]

Is the IRR bit automatically cleared when 8259 receives EOI?
In my test, the IRR of 8259 initially is 0x05. After I hit a key, it reads as 0x07 in the interrupt handler, which means the key irq bit in IRR is set. However sending EOI to 8259 doesn't clear the bit. The IRR still reads as 0x07.
Have any one had this problem?

[bewing]

AFAIK, the EOI is supposed to do it. If you are dealing with a level-triggered INT from a PCI device that hasn't been cleared, then the 8259 should send you another INT at that point. Have you tried doing an STI, and see if the CPU gets another interrupt? Maybe the 8259 is just remembering the last historical INT that it sent? (I don't test the IRR myself -- I just wait for IRQs).

[Brendan]

Hi,

Is the IRR bit automatically cleared when 8259 receives EOI?

No...

When an IRQ is received the corresponding IRR bit is set. When the IRQ is sent to the CPU (and acknowledged by the CPU) the corresponding IRR bit is cleared and the corresponding ISR bit is set. When the EOI is sent the corresponding ISR bit is cleared.

In my test, the IRR of 8259 initially is 0x05.

That'd mean the PIC is waiting to send IRQ 0 and IRQ 2 to the CPU, which shouldn't be possible because IRQ 0 is the highest priority IRQ and would be sent to the CPU as soon as the PIC receives it.

After I hit a key, it reads as 0x07 in the interrupt handler, which means the key irq bit in IRR is set.

That'd mean the PIC is waiting to send IRQ 0, IRQ 1 (cascade?) and IRQ 2 to the CPU. That's even more dodgy (it's unlikely that the slave PIC sent an IRQ, and therefore unlikely that the cascade line changed state).

However sending EOI to 8259 doesn't clear the bit. The IRR still reads as 0x07.

Are you sure you're actually reading the IRR and not something else?


Cheers,

Brendan

[crasher]

I am sorry I didn't write my test environment and procedure.

My test is performed on a quad-core processor.
I have performed two tests. They are as follows.
Test 1:
Local apic is enabled. I also mask all ExtInt type interrupts in LINT0 and LINT1 in local apic. Because the timer interrupt is an ExtInt type set by MP table, the processor will not receive timer interrupt from onwards. I think this is why bit 0 in IRR is never cleared. The MP table also tells key board INTR pin out from 8259A is routed to I/O APIC. So I programmed I/O APIC to set the keyboard interrupt to be 0x21. Then I built the project and restarted the PC. I could catch one keyboard interrupt in the keyboard interrupt handler. Then I wrote a "0" to local apic EOI register according to the Intel Manual Vol3A Chapter 9. The ISR of local apic has changed from 0x02 to 0 after this writing; I also sent specific EOI to 8259 for the safety purpose by using

Code: Select all

outb(0x61, 0x20);

I tried un-specific EOI, too.

Code: Select all

outb(0x20, 0x20);

8259 ISR remained unchanged as 0 both in interrupt handler and after interrupt was returned.

Test 2:
Local apic is disabled. I sent 0x05 to port 0x21 to mask bit 0 and bit 2 of master 8259. Then I rebuilt project and restarted the PC. I could still catch only one keyboard interrupt in the same keyboard interrupt handler. In this test, I didn't send EOI to the local apic EOI register because local apic is disabled. I send EOI to 8259 by using the same way in Test 1. The 8259 ISR changed from 0x02 to 0x00.

[crasher]

This problem is solved by adding “scancode = inb(0x60);â€

[Combuster]

Code: Select all

outb(0x61, 0x20);

Looks like reversed operands to me...