Fixing Hardware Interrupts and IDT Mapping in 32-Bit Protected Mode Operating Systems

Understanding Hardware Interrupts in 32-Bit Protected Mode

When developing a custom 32-bit OS kernel, setting up the Interrupt Descriptor Table (IDT) and Programmable Interrupt Controller (PIC) is a critical milestone. A common problem developers run into is having software interrupts work fine while hardware interrupts (like keyboard presses or timers) trigger unexpected CPU exceptions or crash QEMU entirely.

If pressing a key triggers an exception or triple fault after remapping the 8259 PIC to vector offset 0x20, the issue almost always stems from how IDT descriptors are registered and how vectors are mapped.

1. The Root Cause: Unmapped IDT Entries for IRQs

When you remap the Master PIC to 0x20 (vector 32) and the Slave PIC to 0x28 (vector 40), IRQ 0 through IRQ 15 occupy interrupt vectors 32 to 47 (0x20–0x2F).

Look closely at your idt_init() initialization loop: