patch for "Previous IPI is stuck" - please test
ups at tree.com
Mon Nov 15 13:27:07 PST 2004
There have been several complains about "Previous IPI is stuck" panics
on i386 based multiprocessor systems. In general all affected systems
seem to have four or more real (no HTT) processors.
The local APIC used for IPIs can only queue two interrupts per interrupt
priority class (interrupt vector / 16). Since all IPIs share the same
interrupt priority class more than two IPIs pending to the same
processor will fill the interrupt fifo for the IPI priority class.
I believe the "Previous IPI is stuck" is a deadlock between sending an
AST IPI with sched lock held to a CPU trying to acquire the sched lock
with interrupt disabled and with full interrupt fifo.
Unfortunately I can not reproduce the problem on my dual Xeon with HTT
To test the theory I wrote a patch that replaces multiple IPI interrupt
handlers with a single hander and uses a bitmap to avoid redundant IPI
interrupt requests to the interrupt fifo.
The patch is a proof of concept and therefore not optimized (to put it
mildly ;-). It probably increases the cost for TLB shootdown IPIs
You can download the patch at:
Please make sure that exception.o is rebuild.
( Makefile seems to miss the dependency to apic_vector.s)
Any feedback is appreciated.
More information about the freebsd-current