From owner-p4-projects@FreeBSD.ORG Wed Oct 20 19:10:58 2004 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id DF44016A53D; Wed, 20 Oct 2004 19:10:57 +0000 (GMT) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F09E616A531 for ; Wed, 20 Oct 2004 19:10:56 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6FC243D2D for ; Wed, 20 Oct 2004 19:10:56 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 31470 invoked from network); 20 Oct 2004 19:10:56 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 20 Oct 2004 19:10:56 -0000 Received: from [10.50.41.228] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i9KJAlbh059480; Wed, 20 Oct 2004 15:10:52 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Julian Elischer Date: Wed, 20 Oct 2004 12:58:26 -0400 User-Agent: KMail/1.6.2 References: <200410192159.i9JLxNLE003024@repoman.freebsd.org> <417592DB.6050609@elischer.org> In-Reply-To: <417592DB.6050609@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410201258.26325.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Perforce Change Reviews Subject: Re: PERFORCE change 63396 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 19:10:58 -0000 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@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 <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org