The linux-kernel mailing list is the place to do it, but I doubt anyone is going to care about a bug in 2.6.22.9. If you find the problem in 2.6.27 someone will probably take interest.
Ali On Nov 21, 2008, at 12:08 AM, Gabe Black wrote: > 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 > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
