Date: Wed, 6 Jul 2011 16:36:33 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: KOT MATPOCKuH <matpockuh@gmail.com> Cc: Doug Barton <dougb@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: named crashes on assertion in rbtdb.c o? sparc64/SMP Message-ID: <20110706143632.GA85141@alchemy.franken.de> In-Reply-To: <20110706095514.GF14797@alchemy.franken.de> References: <BANLkTi=NRoyo_J-y5cA4LVJOXWaQMHE0sw@mail.gmail.com> <20110628155802.GA26562@alchemy.franken.de> <4E13B26D.6060203@FreeBSD.org> <20110706095514.GF14797@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 06, 2011 at 11:55:15AM +0200, Marius Strobl wrote: > On Tue, Jul 05, 2011 at 05:55:09PM -0700, Doug Barton wrote: > > On 06/28/2011 08:58, Marius Strobl wrote: > > >Uhm, we once fixed a problem in the MD atomic implementation which > > >still seems to present in the ISC copy. Could you please test whether > > >the following patch makes a difference? > > >http://people.freebsd.org/~marius/sparc64_isc_atomic.h.diff > > > > I haven't seen any verification from the OP that this patch solved the > > problem, > > It simply doesn't so apparently there's another bug in other parts of > BIND causing it to trip over that assertion. Still, the clobber lists > of the sparc64 atomic bits were incomplete and fixing that IMO was the > right thing to do. > MATPOCKuH, could you please test the following patch? http://people.freebsd.org/~marius/sparc64_isc_disable_atomic.diff That one simple disables the use of atomic operations for sparc64 as I doubt that these have seen much testing except on x86, be it on sparc64 or in general; given that they are also used for reference counting they should provide acquire and release semantics for that purpose which include the necessary memory barriers for these but the ISC atomic API simply doesn't account for that. Moreover, the sparc64 implementation of the ISC atomic operations is FreeBSD-specific as it's the only OS I'm aware of using the primary instead of the secondary MMU context for the userland (i.e. ASI_P; generally this is a wise choice though), i.e. don't work on the other *BSDs, Linux or Solaris. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110706143632.GA85141>