OSDev.org

My kernel runs perfectly in VirtualBox and real hardware, but recently it began to misbehave in Bochs, and I cannot tell what the reason might be.

As soon as it disabled the PIC and configured the I/O APIC, then configured PIT and the APIC timer, it enabled interrupts. Then, IRQ1 arrives as interrupt 33, IRQ0 arrives once (as interrupt 32), but then, for some reason, interrupt 8 arrives, but does NOT push an error code (which means it's not a real double-fault). So it seems like it's the "misdiagnosed IRQ0" problem, but how, if IRQ0s already arrived as INT 32, and it also works everywhere but not in Bochs?

I can tell that no error code was pushed because for the interrupts where an error code is not pushed, my kernel pushes a "fake" error code of 0. Since it does expect an error code to be pushed by the CPU in this case, it does not push the fake error code, and since no error code was actually pushed by the CPU, the register structure in on the stack is corrupt, and for example, the code segment is placed where RIP should be (you can see that RIP=8):
Strangely though, the stack pointer should be in the SS field, and it is, but it's rotated shifted right by 8 bits (compare with RBP).

What could be causing this random INT 8, and only in Bochs?

Spurious IRQ from the PIC?

I just happened to be looking through the APIC documentation today, and it mentions something about the PIC still being able to fire off spurious IRQs, even if all vectors have been masked.

Just a guess

Disable the 8259 PIC properly. This is nearly as important as setting up the APIC. You do this in two steps: masking all interrupts and remapping the IRQs. Masking all interrupts disables them in the PIC. Remapping is what you probably already did when you used the PIC: you want interrupt requests to start at 32 instead of 0 to avoid conflicts with the exceptions. This is necessary because even though you masked all interrupts on the PIC, it could still give out spurious interrupts which will then be misinterpreted from your kernel as exceptions.

As already mentioned, the PIC may be generating spurious IRQs. However, that's unlikely because if you didn't remap the PIC, spurious IRQs wouldn't use INT 8 because the BIOS uses INT 8 for IRQ 0.
Also, the PIC can queue IRQs, so one IRQ may happen after you mask it. So after disabling the PIC, give it a short delay to handle the IRQs. So, before remapping the PIC, mask it, and set up INT 8-15 just to send EOI.
This issue also happened to me, before, in Bochs only as well.

Could i also just map the PIC to a completely different interrupt range and make that range do nothing other than send EOI to the PIC?

If it actually were a spurious interrupt, you'd get IRQ 7. If it's not a double fault then the only alternative is the delivery of a real IRQ 0. If you are concerned about that, you should check the order of your code to see if the PIT has been allowed to trigger a pending requests before shutting off the source.

That does not mean you should be treating the PIC properly, and make sure it can't mess up the system by accident as it will formally still be allowed to fire the spurious IRQ7/IRQ15 even if all inputs have been shut off and masked.

Combuster wrote:If it actually were a spurious interrupt, you'd get IRQ 7. If it's not a double fault then the only alternative is the delivery of a real IRQ 0. If you are concerned about that, you should check the order of your code to see if the PIT has been allowed to trigger a pending requests before shutting off the source.

That does not mean you should be treating the PIC properly, and make sure it can't mess up the system by accident as it will formally still be allowed to fire the spurious IRQ7/IRQ15 even if all inputs have been shut off and masked.

As far as I know, the BIOS may have been using the PIT, so I can't predict if it fired off some interrupts before I could handle them.