OSDev.org

Isaac wrote:Do I have to write code for IRQ2 (cascade for slave PIC)?

I don't think that you need to handle this interrupt, because the master PIC will convert it to the correct interrupt for you, but I could be wrong.

The wiki article on Interrupts states that IRQ 2 and 9 are never raised.

Hi,

SpyderTL wrote:

Isaac wrote:Do I have to write code for IRQ2 (cascade for slave PIC)?

I don't think that you need to handle this interrupt, because the master PIC will convert it to the correct interrupt for you, but I could be wrong.

The wiki article on Interrupts states that IRQ 2 and 9 are never raised.

IRQ2 can never happen (due to "cascade").

The wiki article is wrong about IRQ 9 - it's no different to any other IRQ line, and may be used by ISA devices or PCI devices (especially for older systems). For newer systems IRQ 9 tends to be used by ACPI (for its "system controller interrupt" or SCI), but nothing prevents a chipset from using a different IRQ instead.

Note that for ACPI there's basically 2 modes. Either the OS has taken control of ACPI (and the chipset's "system controller" sends SCI to the OS, and the OS handles the SCI by interpreting ACPI's AML), or the OS has not taken control of ACPI. If the OS hasn't taken control of ACPI yet, then the chipset's "system controller" doesn't send the SCI - instead, it sends an SMI and the firmware's SMM code handles the SMI.

This means that if ACPI happens to be using IRQ 9 (which isn't guaranteed), and if the OS hasn't take control of ACPI (like it probably should one day), then IRQ 9 wouldn't occur.

Note: I've edited the wiki page now...


Cheers,

Brendan

Here is a piece of code from the BrokenThorn OSDev tutorial about the PIC: From this code it looks like the primary PIC uses 8 interrupt entries, which means that IRQ 2 uses an interrupt entry. How can that be?

Isaac wrote:Here is a piece of code from the BrokenThorn OSDev tutorial about the PIC:

Code: Select all

; send ICW 2 to primary PIC
	mov	al, 0x20		; Primary PIC handled IRQ 0..7. IRQ 0 is now mapped to interrupt number 0x20
	out	0x21, al
 
	; send ICW 2 to secondary controller
	mov	al, 0x28		; Secondary PIC handles IRQ's 8..15. IRQ 8 is now mapped to use interrupt 0x28
	out	0xA1, al

From this code it looks like the primary PIC uses 8 interrupt entries, which means that IRQ 2 uses an interrupt entry. How can that be?

The code above simply tells the Master PIC and Slave PIC which interrupts to use. If you specify interrupt 10h, that particular PIC will use interrupt 10h through 17h.

It's just so happens that, due to the way that the two PICs communicate with each other, that you will never see an interrupt from IRQ2, but it still technically gets assigned an interrupt, just like any other IRQ. You can safely ignore this interrupt if it ever happens. Which it won't...