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 [EMAIL PROTECTED] -- Nate _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"