cvs commit: src/sys/amd64/amd64 intr_machdep.c src/sys/i386/i386 intr_machdep.c src/sys/ia64/ia64 interrupt.c src/sys/powerpc/powerpc intr_machdep.c src/sys/sparc64/sparc64 intr_machdep.c

[Nate Lawson]

Scott Long wrote:
> scottl      2007-11-21 04:03:51 UTC
> 
>   FreeBSD src repository
> 
>   Modified files:
>     sys/amd64/amd64      intr_machdep.c 
>     sys/i386/i386        intr_machdep.c 
>     sys/ia64/ia64        interrupt.c 
>     sys/powerpc/powerpc  intr_machdep.c 
>     sys/sparc64/sparc64  intr_machdep.c 
>   Log:
>   Extend critical section coverage in the low-level interrupt handlers to
>   include the ithread scheduling step.  Without this, a preemption might
>   occur in between the interrupt getting masked and the ithread getting
>   scheduled.  Since the interrupt handler runs in the context of curthread,
>   the scheudler might see it as having a such a low priority on a busy system
>   that it doesn't get to run for a _long_ time, leaving the interrupt stranded
>   in a disabled state.  The only way that the preemption can happen is by
>   a fast/filter handler triggering a schduling event earlier in the handler,
>   so this problem can only happen for cases where an interrupt is being
>   shared by both a fast/filter handler and an ithread handler.  Unfortunately,
>   it seems to be common for this sharing to happen with network and USB
>   devices, for example.  This fixes many of the mysterious TCP session
>   timeouts and NIC watchdogs that were being reported.  Many thanks to Sam
>   Lefler for getting to the bottom of this problem.
>   
>   Reviewed by: jhb, jeff, silby
>   
>   Revision  Changes    Path
>   1.35      +1 -1      src/sys/amd64/amd64/intr_machdep.c
>   1.30      +1 -1      src/sys/i386/i386/intr_machdep.c
>   1.62      +1 -1      src/sys/ia64/ia64/interrupt.c
>   1.14      +1 -1      src/sys/powerpc/powerpc/intr_machdep.c
>   1.28      +1 -1      src/sys/sparc64/sparc64/intr_machdep.c

Horrible bug, thank you to you and Sam!  Maybe this will fix some other
preemption issues reported to me by bde at .

-- 
Nate