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

From: Jeremy Fitzhardinge
Date: Fri Aug 01 2008 - 13:48:34 EST


Eric W. Biederman wrote:
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.

OK, that's more or less my mental model too.

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.

Yes and no. The event channels are similar to the actual interrupt wires coming out of a PCI card, but they generally connect to virtual devices, and so are a lot more dynamic than physical devices. The event channel remapping scenario I described is pretty much exactly analogous to having a hotplug PCI device being pulled and then replugged into a different slot with a different interrupt line.

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.

Yeah, plugging can happen as a quite regular thing.

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.

Yes, it's a bit odd, but there are two distinct configurations where it's a useful thing to have, where the system is running in a hybrid Xen/native environment.

J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/