Re: kernel BUG at arch/x86/kernel/io_apic_64.c:357!

[ebiederm@xmission.com (Eric W. Biederman)]

Jeremy Fitzhardinge <jeremy@goop.org> writes:

>> Generally easy except for the disparate methods of catching interrupts.
>>
>
> Catching in what sense?  I assume the interrupt gets raised in some
> source-specific way, and then passed into a generic layer where it eventually
> gets matched with an appropriate handler.  I'm sure there's some subtlety I'm
> missing.

Sorry.  Probably too much context in my head.
The model I use is irq sources throw interrupts and then the cpus catch them.
Sometimes those in flight irqs go through several transformations.

Given that the event channels that logical irq are bound to change over time
I would say they appear to be not irq sources.  Those are the physical
lines coming out of hardware devices (if physical), and the equivalent
parts of the hardware when the irqs are sent message based.

So it does sound like the event channels function much like vectors.  Which
are the token thrown from ioapics to cpus to tell them which irq has happened
but have nothing to do with it.

The sources and the linux irq numbers should be stable if you don't unplug
anything.  The rest are implementation details the architecture should hide.

In that case I don't see any reason we could not be receiving irqs with the
cpus catching vectors and with events showing up in event channels.  Having
both running at the same time is a little odd but doable.

Eric