> Raphael Manfredi wrote:
> I just triggered the bug using a couple of simultaneous "ping -f -s 10
> host" commands, and the patched kernel indeed recovers from the bug with
> a "kernel: Kicking IO-APIC IRQ 17:" message :)
> Now if only we could call the recovery mechanism from the point where
> the "unexpected IRQ trap at vector" message gets printed (in
> arch/i386/kernel/irq.c:ack_none), then we would have a lot more generic
> code for all kinds of devices. If we then surround it by an #ifdef
> CONFIG_BROKEN_APIC like Helge suggested, there's more chance this patch
> gets accepted.
> Problem now is, in the ack_none function we only know about the
> (illegal) vector we are getting, and not about the interrupt we need to
> reset. Could there be some kind of link between these, so that
> kick_IO_APIC_irq can be called from there?
Interesting, i haven't come across this problem before but it sounds like
the vector isn't getting delivered when the interrupt gets asserted and
only gets triggered later followed by an EOI... or something. Then again
its probably been beaten around a couple of times by now so i probably am
not adding anything new.
arch/i386/kernel/io_apic.c:irq_vector seems to be what you're looking for.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/