I've got a semi-relevant question for folks familiar with the Linux
kernel development process. In the 2.6.22.9 kernel in
setup_ExtINT_IRQ0_pin on line 868 of arch/x86_64/kernel/io_apic.c, there
seems to be a bug in how the IO APIC redirection table entry is set up
to route the timer interrupt from the master I8259. Basically, the
I8259(s) is(are) the legacy interrupt controller which has legacy
interrupts connected to it which are also connected to the IO APIC. The
I8259 is connected to the IO APIC as well on pin 0. To use the I8259,
roughly speaking, you unmask the pin your interested in, and it'll
wiggle pin 0 of the IO APIC when any of its interrupts is triggered. The
IO APIC has a table which describes what to do for any of it's pins, and
the entry for pin 0 is supposed to say that this interrupt is really
forwarded from an external interrupt controller, basically always the
master I8259. The IO APIC sends a message to the Local APIC the CPU(s)
which will handle the interrupt. When that CPU accepts the interrupt, it
sends an acknowledge message back onto the bus, and the IO APIC lets the
I8259 tell the APIC what vector it should use. It looks something like this.
1. timer interrupt triggers master I8259 pin 0.
2. I8259 triggers IO APIC pin 0.
3. IO APIC tells the local APIC it got an interrupt and it was from
somebody else.
4. The local APIC asks for that somebody else to tell it what vector it
wanted.
What I think is the bug is that the delivery mode, the thing that
says, among other possibilities, that the interrupt came from somebody
else is not being set that way. It works for the timer interrupt since
the IO APIC table entry is being set so that the same vector gets where
it needs to go, but for any other I8259 interrupt, the IO APIC doesn't
know it's not the same pin 0, so it sends the timer interrupt vector all
the time and the I8259 gets ignored. The CPU also doesn't see the
interrupts it may be expecting, specifically the "I've got keyboard
data" interrupt from the keyboard controller which is how I found this
in the first place.
Anyway, the thing I wanted to ask was how do I go about letting the
right person know something may be wrong here? The 32 and 64 bit
versions of the code get merged in a later version of the kernel so the
entire file goes away at some point. The function name isn't around any
more, so it may have just been taken out entirely. I'm not even sure if
this is actually a bug, or if I'm just not understanding how it's
supposed to work.
To deal with the problem in the immediate term I'm going to actually
connect the legacy interrupts to the IO APIC as well so Linux doesn't
try to use the I8259 at all.
Gabe
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
