Searched hist:94778 (Results 1 - 3 of 3) sorted by last modified time
| /freebsd-10.1-release/ | ||
| H A D | MAINTAINERS | diff 94778 Mon Apr 15 14:01:41 MDT 2002 imp Add my level of stuff preference to MAINTAINERS |
| /freebsd-10.1-release/sys/sparc64/sparc64/ | ||
| H A D | exception.S | diff 157825 Mon Apr 17 19:03:24 MDT 2006 marius - 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 |
| H A D | interrupt.S | diff 157825 Mon Apr 17 19:03:24 MDT 2006 marius - 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 |
Completed in 99 milliseconds