bochs generating interrupt 8 for no reason suddenly

[mariuszp]

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):

Code: Select all

DS:  0xFFFF8000001A0010	SS:  0x9FFFFF8000001043
RDI: 0xFFFF8000001B2298	RSI: 0x0000000000000007
RBP: 0xFFFF80000010437F	RSP: 0x0000000000000000
RAX: 0xFFFF8000001ADB30	RBX: 0xFFFF8000001001B0
RCX: 0x0000000000000780	RDX: 0x00000000000003D5
R8:  0x0000000000000002	R9:  0xFFFF800000141486
R10: 0x0000000000000000	R11: 0x0000000000000000
R12: 0x0000000000000000	R13: 0x0000000000000000
R14: 0x0000000000000000	R15: 0x0000000000000000
INO: 0x0000000000000008	ERR: 0xFFFF80000018E1AD
CS:  0x0000000000200246	RIP: 0x0000000000000008
RFLAGS: 0xFFFF80000010431F (CPAZSTIDONR)
In function isrHandler at src/idt.c:535
Kernel panic: Unhandled interrupt: 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?

[SpyderTL]

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.

[BrightLight]

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.

[mariuszp]

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?

[Combuster]

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.

[mariuszp]

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.