From owner-freebsd-current@FreeBSD.ORG Thu Aug 26 17:37:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BAA416A4CE; Thu, 26 Aug 2004 17:37:59 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49CD243D6D; Thu, 26 Aug 2004 17:37:59 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 107AF72DD4; Thu, 26 Aug 2004 10:37:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 0B1EE72DCB; Thu, 26 Aug 2004 10:37:59 -0700 (PDT) Date: Thu, 26 Aug 2004 10:37:59 -0700 (PDT) From: Doug White To: Garance A Drosihn In-Reply-To: Message-ID: <20040826103652.F36995@carver.gumbysoft.com> References: <20040822115345.Y94593@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: PLEASE TEST: IPI deadlock avoidance patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 17:37:59 -0000 On Mon, 23 Aug 2004, Garance A Drosihn wrote: > At 12:05 PM -0700 8/22/04, Doug White wrote: > >Hey folks, [...] please try this patch: > > > >http://people.freebsd.org/~dwhite/smp_rv_mtx.patch > > > >This patch avoids a deadlock between the smp_rendezvous() > >mechanism and TLB shootdowns via pmap by forcing them to > >share a mutex. > > I have completed a series of buildworlds with -j3 to -j10 with > no problem. I then started up a "folding at home" client, and > repeated the buildworlds. No panics, but in the second set I > did have one buildworld (-j9) which failed with four processes > apparently getting a "*** Signal 6". I am not sure what that > was about. Note that all these builds were done with a `make' > that was compiled to USE_KQUEUE , so maybe that's where the > Signal's came from. In any case, the machine is still running > fine, even after that heavy pounding. Signal 6 is SIGABRT, which is usually intentional. You'd have to check the output for a specific process that abended. I'd also have to scan the make code for any abort() calls. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org