x86: handles spurious IRQs from the PIC and LAPIC
authorBarret Rhoden <brho@cs.berkeley.edu>
Thu, 5 Apr 2012 19:34:51 +0000 (12:34 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 5 Apr 2012 21:23:58 +0000 (14:23 -0700)
commit51e297490e7a7bd9a350d54da4ade20ce964aeba
treea23b0759bba7c8a5db25612f3361a421b0f2d18a
parent23de6bb0ab1d3b9649a2f70dfee22184c615bf1d
x86: handles spurious IRQs from the PIC and LAPIC

I put printks in there, since I'm curious to see if this even happens
and haven't been able to test it yet.  Once it happens, we'll turn off
the printks.

Note things get a little confusing when talking about IRQ numbers.
The kernel's IRQs are mapped 32 (PIC1_OFFSET) slots higher than
hardware's IRQs.  For instance, what the PIC things of as IRQ0 comes in
to irq_handler as 32.  When talking to the PIC/hardware, we use their
numbers.  Devices, like the Keyboard on IRQ0 need to get registered at 0
+ PIC1_OFFSET.  Might clean this up over time, but there's no getting
around the offset/remapping.

Also, make sure you never tell the LAPIC/IOAPIC to use a PIC IRQ if you
are also using the PIC; the kernel won't be able to tell the difference.
I might be able to change this, but it's not a real problem.
kern/arch/i686/apic.h
kern/arch/i686/trap.c