Closed awesomekling closed 2 years ago
https://wiki.osdev.org/8259_PIC#Spurious_IRQs It's probably a spurious IRQ happening due to a malfunction somewhere in the code. I'll implement an handler for such type of IRQs, but there is a problem somewhere in the EOI code (probably). I'll check it.
We're not done yet. Now Spurious IRQs are handled, but we need to make sure they don't appear at all. For that, we should enable the IOAPIC & MSIs if possible, since Spurious IRQs are mostly related to timing issues of IRQs.
@awesomekling and I talked about the Spurious IRQs' bug today, and I start to think it's not about the fact that we use the PIC (which should be slower than the APIC on real hardware), but due to the fact that priorities are handled so IRQ0 is more important than IRQ10 for example. The network card is connected to IRQ11 AFAIK in the i440fx QEMU machine type, therefore, it could be related to that. However, currently we do an identity mapping on the IOAPIC too, but, AFAIK the higher the class of the interrupt (the 4 to 7 bits of the interrupt vector), it's more "important" to deliver it first. https://xem.github.io/minix86/manual/intel-x86-and-64-manual-vol3/o_fe12b1e2a880e0ce-390.html https://forum.osdev.org/viewtopic.php?p=173766#p173766
Regardless of that, we should fix the E1000 driver, as it relies on kmalloc and that's not very good.
I suspect that spurious IRQs are generated because of this code section: https://github.com/SerenityOS/serenity/blob/0d2fb306afac1d0d698b2a0bcba47e011f0cc852/Kernel/Net/E1000NetworkAdapter.cpp#L397-L411
I'm not 100% sure about this, but since we can still get sometimes spurious IRQs on heavy loads from E1000 adapter, there's a problem related to the E1000 code.
This has long been fixed.
To reproduce:
Some stuff loads, then we get this message and the machine hangs:
cc @supercomputer7