Neverending Exceptions?

[campital]

Time for my first post! So, I am having problems setting up the GDT and IDT (or it could have occured somewhere else). What happens is an exception is immediately triggered when the STI instruction is executed. I have observed that it initially starts out with a double fault (afaik), but to my knowledge it is not pushing an error code like it should, throwing off the stack. If I remove the

Code: Select all

add esp, 4

, only one exception is triggered and the instruction pointer register seems to hang at a weird place in memory without going anywhere afterwards. I have dumped the memory where the tables reside, and they look normal to me. The stack also doesn't seem to have the necessary information for IRET before it is executed. Can anyone find my error?
...
Edit:
Conclusion: Because I had written my own bootloader, the PIC was incorrectly mapped to the exception interrupts and I needed to manually reprogram it. Thanks Brendan!

[Brendan]

Hi,

Time for my first post! So, I am having problems setting up the GDT and IDT (or it could have occured somewhere else). What happens is an exception is immediately triggered when the STI instruction is executed. I have observed that it initially starts out with a double fault (afaik), but to my knowledge it is not pushing an error code like it should, throwing off the stack.

That's not a double fault, it's a PIT (Programmable Interval Timer) IRQ.

Unfortunately, once upon a time (a long time ago) Intel said "the first 32 interrupt vectors are reserved for exceptions" and IBM decided to ignore Intel's advice by configuring the PIC (Programmable Interrupt Controller) chip to use interrupts 0x08 to 0x0F. Then Intel added more functionality that used more (previously reserved/unused) interrupts for exceptions, but it was too late - for compatibility with IBM's PC everyone had to keep using interrupts 0x08 to 0x0F for IRQs. Because of this, the default is for the PIT (which is IRQ0) to use interrupt 0x08, even though this interrupt is also used for the double fault exception handler. Note: After the original mistake had been made, IBM added a second PIC chip in a "master and slave" configuration, where the original PIC chip became the "master PIC chip" and had to continue using interrupts 0x08 to 0x0F, but the new "slave PIC chip" used interrupts 0x70 to 0x77 to avoid interrupts reserved for exceptions.

To fix this, every newer OS (that doesn't have to care about compatibility) reconfigures the PIC chips so that IRQs aren't using interrupts that are reserved for exceptions. E.g. most people reconfigure the PICs so that interrupts 0x20 to 0x27 are used for the master PIC and interrupts 0x28 to 0x2F are used for the slave PIC.

The correct way to do this is to mask everything in both PIC chips, then let BIOS handle any "pending" IRQs (with no real reason to bother using "CLI" or "STI" because all IRQs are masked anyway); then reconfigure the PIC chips; then unmask each IRQ if/when a device drivers needs that specific IRQ.

Unfortunately a lot of people do this wrong (and/or they use GRUB which does it wrong) - they'll do "CLI", then they'll do other stuff while any IRQs that occur become "unhandled pending IRQs" because they weren't masked; then they'll reconfigure the PIC chips (which doesn't clear out any "unhandled pending IRQs"), then they'll do more other stuff while more IRQs will become "unhandled pending IRQs", and then they'll do "STI" and immediately after that they'll receive any "unhanded pending IRQs" that should've been masked but weren't.


Cheers,

Brendan

[dragon7307]

Hey, sorry to chime in 7 years late on the party, but I've coincidentally stumbled upon this threat as I am currently (desperately yearning for a fix) experiencing the exact same problems as the op and the mistakes you described could apply to me.

So just to get this right, you're saying that I should issue two outb commands right at the start of my custom bootloader (still in real mode) like so:

Code: Select all

mov al, 0xFF
out 0x21, al
out 0xA1, al

This would mask out any further interrupts and the BIOS could - over the remainder of my bootloader - clear up all pending IRQS. Then I just unmask those I need once I've setup interrupts in protected mode?

Many thanks

EDIT: It seems to have solved the problem. Thank you, really!

[Octocontrabass]

So just to get this right, you're saying that I should issue two outb commands right at the start of my custom bootloader (still in real mode) like so:

Brendan is incorrect, that's unnecessary. You only need a CLI instruction before you switch to protected mode (but after you finish calling BIOS functions).

This would mask out any further interrupts and the BIOS could - over the remainder of my bootloader - clear up all pending IRQS.

The BIOS can't clean up pending interrupts if it never receives them. It also doesn't need to, because initializing the PICs will clean up pending interrupts anyway.

EDIT: It seems to have solved the problem.

You've only hidden the problem. There are still situations where you can receive an interrupt before you're prepared to handle it. The correct solution is to move the STI instruction to after you're done initializing the PICs.

[dragon7307]

Yes, as soon as I try to reenable them it breaks. You're correct. It only postpones the issue. Yet I have already (or at least should) initialized the pic and remapped the interrupts - to no avail apparently. The interrupt seems to persist as a v=08 without error code. See here for details: viewtopic.php?p=350778#p350778