From owner-freebsd-fs Wed Dec 11 15: 7:59 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7883A37B401 for ; Wed, 11 Dec 2002 15:07:58 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E54B243EA9 for ; Wed, 11 Dec 2002 15:07:57 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id gBBN7kBF041140; Wed, 11 Dec 2002 18:07:46 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 11 Dec 2002 18:07:46 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Rashim Gupta Cc: fs@freebsd.org, bright@mu.org Subject: Re: kernel panic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 11 Dec 2002, Rashim Gupta wrote: > On compiling a custom kernel I am getting the following error. I am > writing a journaled file system and I cannot seem to understand why I > keep getting this error. Can we assume from this that this error is not occuring in the stock code? > panic: ffswrite: type 0xc1f7fcb8 0 (0,4) > > Any suggestions what this error might be due to? Also, it is not a > persistent error. If I reboot my machine using the same kernel at times > I get this error and at times I do not. Thanks in advance Rashim A casual read of that FFS code shows that the error occurs in ffs_write(), and that it occurs when the vnode type is not an expected or handled type. 0 is probably VNON, so if I had to guess, your vnode has been revoked via revoke() or forceable unmount. Or, the reference count got dropped on the vnode and the memory was recycled for other use, resulting in the type getting zero'd. However, having gotten into the VOP means that (at least recently), the vnode function pointer was pointing at the FFS operation vector rather than the deadfs operation vector. To identify the type of race and/or nastiness, I suggest inspecting the remainder of the vnode structure using a debugger. Check the current reference counts, value of the operation vector pointer, lock information, etc. There is a known race involving deadfs and revoke() that could be at work, but it could easily also be a local race condition involving reference counts. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message