We've run into a hitch in the v2.5 Summit interrupt code. When balance_irq()
targets an I/O APIC interrupt to an idle CPU, the interrupt really goes to
CPU 0 of the APIC cluster, no matter which one it was supposed to interrupt.
These IRQs are in lowest priority mode, but only one bit is set (correctly)
in the low nibble. (The high nibble contains the APIC cluster number, the
low nibble is a bitmap of CPUs in the cluster.)
When we change the delivery mode from lowest priority to fixed, IRQs go where
they should. However, this reintroduces some code from v2.4 that we were
trying to simplify and remove.
Anyway, is this a known erratum for xAPICs in parallel mode? (Namely, a bug
in the XTPR arbitration logic in host bridges.)
Can anyone at Intel or otherwise enlighten me?
For that matter, does this happen on non-Summit xAPIC boxes? Anyone out there
with a >= 2 CPU P4 box that uses parallel interrupts care to comment?
--
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/