From owner-freebsd-stable@FreeBSD.ORG Fri Jan 16 13:51:30 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 027791065674; Fri, 16 Jan 2009 13:51:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D27198FC1C; Fri, 16 Jan 2009 13:51:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 7485A46B0C; Fri, 16 Jan 2009 08:51:29 -0500 (EST) Date: Fri, 16 Jan 2009 13:51:29 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Pete French In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, drosih@rpi.edu, dchagin@freebsd.org, rblayzor.bulk@inoc.net Subject: Re: Big problems with 7.1 locking up :-( X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 13:51:30 -0000 On Fri, 16 Jan 2009, Pete French wrote: >> hi, please type: show lock 0xffffff0001254d20 and then show thread >> 0xXXXXXXXXXXX where XXXXX is 'owner' of previous output. > > http://toybox.twisted.org.uk/~pete/71_pdns_lock.png > > That's in Power DNS - which is interesting because the one difference > between the boxes that lock and those which dont is that the locking ones > are serving DNS. I rather feared as much. Let's run down the path of "perhaps there's a problem with the new UDP locking code" for a bit and see where it takes us. Is it possible to run those boxes with WITNESS -- I believe that the fact that "show alllocks" is failing is because WITNESS isn't present. The other thing we can do is revert UDP to using purely write locks -- the risk there is that it might change the timing but not actually resolve the bug, so if we can analyze it a bit using WITNESS first that would be useful. Robert N M Watson Computer Laboratory University of Cambridge