From owner-freebsd-stable@FreeBSD.ORG Mon Mar 15 02:31:34 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC11F16A4CE for ; Mon, 15 Mar 2004 02:31:34 -0800 (PST) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12B8543D2D for ; Mon, 15 Mar 2004 02:31:34 -0800 (PST) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.222.84) by smtp01.syd.iprimus.net.au (7.0.024) id 402BA92700AA0B0E; Mon, 15 Mar 2004 21:31:03 +1100 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 0577741C0; Mon, 15 Mar 2004 21:31:29 +1100 (EST) Date: Mon, 15 Mar 2004 21:31:29 +1100 From: Tim Robbins To: Pawel Malachowski Message-ID: <20040315103129.GA28318@cat.robbins.dropbear.id.au> References: <20040303134001.GA63144@cat.robbins.dropbear.id.au> <200403080858.JAA18049@galaxy.hbg.de.ao-srv.com> <20040309033529.GA88800@cat.robbins.dropbear.id.au> <20040310181933.GA28452@shellma.zin.lublin.pl> <20040315100524.GA80784@shellma.zin.lublin.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040315100524.GA80784@shellma.zin.lublin.pl> User-Agent: Mutt/1.4.1i cc: stable@freebsd.org Subject: Re: Using read-only NULLFS leads to panic. gdb output included, e asy to reproduce. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 10:31:35 -0000 On Mon, Mar 15, 2004 at 11:05:24AM +0100, Pawel Malachowski wrote: > On Wed, Mar 10, 2004 at 07:19:33PM +0100, Pawel Malachowski wrote: > > > > Here's the patch against RELENG_4: > > > http://people.freebsd.org/~tjr/nullfs-4.diff > > > > > > It works, but I'm not going to commit it until I've had time to > > > check a few things first. > > > > Successfully tested on my 4.9-STABLE box, thanks. > > Well, I shoot myself in the foot. > > After 2 days, my 4.9-RELEASE machine caught o problem again. > Not panic, new processess trying to access one of filesystems > were stopping at `inode' state (for example >3k crons). System > was also not able to shutdown properly. Next time this happens, break into ddb and save backtraces of a few processes stuck in the inode state with the "tr " command. If you don't have a serial console, just jot down the first few lines of each backtrace. Try to collect at least 2 different traces - most of them will be identical. If the bug you're running into is the one I think it is, reducing the value of kern.maxvnodes may make it easier to reproduce (and conversely, increasing the value will mask the bug somewhat.) Tim