338199fe88
above what's used for fast interrupts, only interrupts with the level of the interrupt which led to calling intr_fast() (which is used with both fast and ithread interrupts) are blocked while in that function. Thus intr_fast() can be preempted by a fast interrupt (which are of a higher level than ithread interrupts) while servicing an ithread interrupt. This can lead to a stale pointer to the head of the active interrupt requests list when back in the ithread interrupt invocation of intr_fast(), in turn resulting in corruption of the interrupt request lists and consequently in a panic. Solve this be turning off interrupts in intr_fast() before reading the pointer to the head of the active list rather than after. [1] - Add a KASSERT in intr_fast() which asserts that ir_func is non-zero before calling it. [1] - Increment interrupt stats after calling the handlers rather than before. This reduces the delay until direct and fast handlers are serviced, in my testings by 30% on average for the direct tick interrupt handler, in turn resulting in less clock drift. PR: 94778 [1] Submitted by: Andrew Belashov [1] MFC after: 2 weeks |
||
---|---|---|
.. | ||
central | ||
compile | ||
conf | ||
creator | ||
ebus | ||
fhc | ||
include | ||
isa | ||
pci | ||
sbus | ||
sparc64 |