PERFORCE change 63396 for review

[Brian Fundakowski Feldman]

On Wed, Oct 20, 2004 at 12:58:26PM -0400, John Baldwin wrote:
> 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.

Isn't this what I said a few weeks ago was probably the problem?

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\