From owner-freebsd-stable@FreeBSD.ORG Tue Jan 13 16:10:50 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 93ED91065672; Tue, 13 Jan 2009 16:10:50 +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 6EBC98FC14; Tue, 13 Jan 2009 16:10:50 +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 2A42646B58; Tue, 13 Jan 2009 11:10:50 -0500 (EST) Date: Tue, 13 Jan 2009 16:10:50 +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: dougb@freebsd.org, freebsd-stable@freebsd.org, kometen@gmail.com 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: Tue, 13 Jan 2009 16:10:50 -0000 On Tue, 13 Jan 2009, Pete French wrote: >> I can't (fortunately) make it lock up. I have a DL360 G5 which is unused >> atm. and can test on it if needed. > > Would it be possible to install that under amd64 and hammer it with DNS > requests ? I have been trying to think what the difference might be between > my webservers and the machines which are freezing, and the opnly one I an > come up with is UDP traffic as the locking machines are serving DNS and also > NFS. There are significant changes in UDP locking between 7.0 and 7.1, so it could be that we're looking at a regression there. If you're able to reproduce this reliably, it might well be worth doing a little search-and-replace in udp_usrreq.c along the following lines: INP_RLOCK_ASSERT -> INP_WLOCK_ASSERT INP_RLOCK -> INP_WLOCK INP_RUNLOCK -> INP_WUNLOCK However, before making these changes for debugging purposes, make sure it's 100% reproduceable without them in the configuration so that we don't find ourselves barking up the wrong tree. Normally deadlocks along these lines *do* allow breaking into the debugger from a serial console, but since there are significant changes here in 7.1 it is worth trying to see if this might be related. Robert N M Watson Computer Laboratory University of Cambridge