PERFORCE change 63396 for review

John Baldwin jhb at FreeBSD.org
Wed Oct 20 12:10:58 PDT 2004


On Tuesday 19 October 2004 06:19 pm, Julian Elischer wrote:
> John Baldwin wrote:
> >http://perforce.freebsd.org/chv.cgi?CH=63396
> >
> >Change 63396 by jhb at jhb_tibook on 2004/10/19 21:58:24
> >
> >	Update.
> >
> >Affected files ...
> >
> >.. //depot/projects/smpng/sys/notes#21 edit
> >
> >Differences ...
> >
> >==== //depot/projects/smpng/sys/notes#21 (text+ko) ====
> >
> >@@ -33,6 +33,10 @@
> >   - Untested
> > - Don't allow kthreads to get signalled and do bad things
> >   - Untested
> >+- Change amd64 to use [ls]fence instructions for memory barriers.
> >+  - Untested (and no hardware, maybe peter can test)
> >+- Turn off the ipiwakeups in 4BSD since the currently implementation can
> >+  lead to IPI deadlocks
>
> the implementation of IPIs or the implementation of IPIwakeup?

Kind of hard to say.  The problem is if a CPU tries to send two IPI_AST's 
without enabling interrupts in between.  The first IPI may not be delivered 
when the second one is requested because the target of the first IPI has 
interrupts disabled for some reason (doing a TLB shootdown is the worst case 
scenario).  The other CPU won't enable interrupts to allow the first AST 
until it's shootdown is acknowledged.  Since the first IPI is never 
delivered, then the second IPI attempt will never be able to deliver an IPI, 
resulting in either a panic or deadlock.  My quad xeon is highly unstable on 
HEAD, btw, and this does seem to help it.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the p4-projects mailing list