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