Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I ran into an article that claims that "false interrupts" can still happen after masking all PIC interrupts. And that because of that, one still need to remap the PIC interrupts to offset 32 and not use these interrupts for other purposes.
This doesn't seem to make any sense to me. Have anyone heard of this behaviour?
Disable the 8259 pic correctly. This is almost as important as setting up an APIC. You do this in two steps: masking all interrupts and reassigning the IRQ. Masking all interrupts disables them in the PIC. Trapping interrupts 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 exceptions (in protected and long (Long) processor modes, because . The first 32 interrupts are exceptions). Then you should avoid using these interrupt vectors for other purposes. This is necessary because, despite the fact that you masked all PIC interrupts, it could still produce false interrupts, which would then be incorrectly handled as exceptions in your kernel.
Perhaps they don't mean spurious interrupts but rather that there might be some pending interrupts that will fire once you enable CPU interrupts (STI)?
kzinti wrote:This doesn't seem to make any sense to me. Have anyone heard of this behaviour?
I only know of spurious interrupts, which can happen at all times, anyway. But I have never seen a blip on those sixteen IRQs, either. Still, I have more than enough interrupts available, might as well spend those 16, just to be safe.
I have had the PIC fire a interrupt after being masked in the passed, although it was not disabled (I forget the hardware details as this event has only happened a few times for me, and it was not in a emulator). It does happen very rarely, but it will save a lot of time debugging if it does happen, and it is only a few commands.
I don't think the PIC can raise spurious IRQs once everything is masked in the IMR, but none of the PIC datasheets I checked (8259A, 82C59A, 82C206, 82371FB/SB) specify what happens in that case.
On old hardware that has a separate INTR line instead of using special messages on the CPU's local bus, noise on the INTR line could still cause spurious IRQs that appear to come from the PIC.
