From owner-freebsd-hackers Sun Feb 21 9:44: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 2BF7511C4F for ; Sun, 21 Feb 1999 09:44:00 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id RAA56064; Sun, 21 Feb 1999 17:43:48 GMT (envelope-from dfr@nlsystems.com) Date: Sun, 21 Feb 1999 17:43:48 +0000 (GMT) From: Doug Rabson To: Matthew Jacob Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 21 Feb 1999, Matthew Jacob wrote: > > Sorry to say that during testing last night (in the middle of which a > buildworld got started) the system paniced again with a 'panic: getnewbuf > infinite recursion failure'. I've left it in the debugger if anyone could > suggest looking at something. I'm going to New Orleans tomorrow so it can > sit in the debugger until Friday... > > A very cursory look at the code makes me wonder 'why the value of 5 for a > limit'? It doesn't seem to me a panic is a good solution. Apart from the use of 5 as a 'magic' number, this code doesn't cope with being reentered by another process - the recursion test needs to be on a per-process basis. I'm sure that if you check the stack trace, you won't see any kind of recursion happening. I would suggest disabling it entirely to see if the system survives any better. If that helps, perhaps it should be using a field in struct proc to record the recursion depth. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message