Getting hard interrupts working (soft interrupts work)

[pragmatic]

I am using QEMU/GRUB2 to boot my kernel, so system is already in protected mode once I get execution. I have managed to get software interrupts working, but hardware interrupts still fail when triggered (I have been testing with #1, the keyboard). I am able to successfully:

• - Execute and return from the interrupt handler (ASM and C) installed in the IDT via software interrupts (e.g. int 1)
  - Mask/unmask the keyboard interrupts and observe that interrupts are not received when masked (and keys are struck on the keyboard)

I've written the ISR to write to the video buffer so I can be informed when something happens. This works as expected with software interrupts. However, when triggered via hardware (e.g. hitting a button on the keyboard), QEMU will just triple fault and restart. As such, the ISR does not appear to be being executed when triggered in this way.

As far as I can tell I've cleared myself of most of the common mistakes outlined on the wiki. Does the above seem symptomatic of something anyone else has experienced?

[LtG]

As far as I can tell I've cleared myself of most of the common mistakes outlined on the wiki. Does the above seem symptomatic of something anyone else has experienced?

Like what? Which specific Wiki page are you referring to?

You have re-mapped the PIC? Have you enabled paging (could a page fault occur)?

Add a #DF handler to see what the original fault is.. Also debug with gdb to see what exactly happens. There's an article about gdb in the Wiki I think.

PS. I'd recommend adding all the ISR's that are possible (based on what you set as limit in the IDTR), such that those ISR's simply print an error and halt (ie. kpanic). Then replace those ISR's one by one with real ones. The benefit is that if any unexpected interrupt occurs you'll know about it immediately..

[Brendan]

I am using QEMU/GRUB2 to boot my kernel, so system is already in protected mode once I get execution. I have managed to get software interrupts working, but hardware interrupts still fail when triggered (I have been testing with #1, the keyboard). I am able to successfully:

• - Execute and return from the interrupt handler (ASM and C) installed in the IDT via software interrupts (e.g. int 1)
  - Mask/unmask the keyboard interrupts and observe that interrupts are not received when masked (and keys are struck on the keyboard)

I've written the ISR to write to the video buffer so I can be informed when something happens. This works as expected with software interrupts. However, when triggered via hardware (e.g. hitting a button on the keyboard), QEMU will just triple fault and restart. As such, the ISR does not appear to be being executed when triggered in this way.

As far as I can tell I've cleared myself of most of the common mistakes outlined on the wiki. Does the above seem symptomatic of something anyone else has experienced?

I suspect you may have gotten "int 0x01" and "IRQ 0x01" mixed up. For the default BIOS (mis)configuration of the PIC chips, "IRQ 0x01" is "int 0x09"; but this conflicts with exceptions so everyone reconfigures the PIC chips (and a lot of people choose to configure PIC chips so that "IRQ 0x01" is "int 0x21").


Cheers,

Brendan

[pragmatic]

Like what? Which specific Wiki page are you referring to?

Mostly http://wiki.osdev.org/I_Can%27t_Get_Interrupts_Working.

You have re-mapped the PIC? Have you enabled paging (could a page fault occur)?

I did intentionally skip the remapping step. I saw it more as a required step after I was sure my GDT/IDT were working properly. Of course, this turned out to be exactly my problem.

Add a #DF handler to see what the original fault is.. Also debug with gdb to see what exactly happens. There's an article about gdb in the Wiki I think.

I have been using GDB, but it turns out that improper configuration was causing the triple fault. It's hard to debug the GDT/IDT configuration when the behavior is a hardware-driven triple fault. Now that I understand the problem I can do this more effectively.

I suspect you may have gotten "int 0x01" and "IRQ 0x01" mixed up. For the default BIOS (mis)configuration of the PIC chips, "IRQ 0x01" is "int 0x09"; but this conflicts with exceptions so everyone reconfigures the PIC chips (and a lot of people choose to configure PIC chips so that "IRQ 0x01" is "int 0x21").

This is exactly what the problem was. As mentioned above, I was planning to remap the PIC once I was sure my interrupt configuration was sound. Your wording is a bit confusing, though. My IDT had only a single entry at index 1 (for what I was interpreting to be IRQ1). I was able to successfully execute/return from this interrupt by issuing:

Code: Select all

int 1

After this comment, I added the same entry to index 9 of my IDT and was able to properly handle interrupts from the keyboard.

I suppose I was thinking of the entries in the IDT as "IRQ" handlers, rather than "INT" handlers. It seems they just share the same handler space but with different mappings.
It's mentioned here: http://wiki.osdev.org/PIC#The_IBM_PC.2F ... chitecture

[LtG]

I suspect you may have gotten "int 0x01" and "IRQ 0x01" mixed up. For the default BIOS (mis)configuration of the PIC chips, "IRQ 0x01" is "int 0x09"; but this conflicts with exceptions so everyone reconfigures the PIC chips (and a lot of people choose to configure PIC chips so that "IRQ 0x01" is "int 0x21").

This is exactly what the problem was. As mentioned above, I was planning to remap the PIC once I was sure my interrupt configuration was sound. Your wording is a bit confusing, though. My IDT had only a single entry at index 1 (for what I was interpreting to be IRQ1).

You had set your IDTR limit to 0-1, which means any INT higher than 1 would cause an exception (#GPF), but because you don't have a handler for #GPF (13/0xD, but your limit says only 0 and 1 are valid handlers) it can't be started -> causes double fault (#DF, 8/0x8), which of course you don't have either and thus can't be started -> triple fault -> reboot.

[pragmatic]

You had set your IDTR limit to 0-1, which means any INT higher than 1 would cause an exception (#GPF), but because you don't have a handler for #GPF (13/0xD, but your limit says only 0 and 1 are valid handlers) it can't be started -> causes double fault (#DF, 8/0x8), which of course you don't have either and thus can't be started -> triple fault -> reboot.

Indeed this is true, though I was managing it this way intentionally. I realized the system was triple-faulting but could not figure out why. It turned out to be the mapping of the PIC. However, your point contends with what I thought was happening. Rather than a GPF I was thinking it went straight through to DF -> TF, not GPF -> DT -> TF. Thanks for that bit of info!

I plan to install a default handler for each entry now that I have a working configuration.