Date: Mon, 17 Apr 2006 21:03:24 +0000 (UTC) From: Marius Strobl <marius@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/sparc64/sparc64 exception.S interrupt.S Message-ID: <200604172103.k3HL3O02069714@repoman.freebsd.org>
index | next in thread | raw e-mail
marius 2006-04-17 21:03:24 UTC
FreeBSD src repository
Modified files:
sys/sparc64/sparc64 exception.S interrupt.S
Log:
- Since critical sections no longer raise the processor interrupt level to
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
Revision Changes Path
1.73 +26 -26 src/sys/sparc64/sparc64/exception.S
1.9 +20 -12 src/sys/sparc64/sparc64/interrupt.S
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200604172103.k3HL3O02069714>