From owner-freebsd-current Fri Oct 11 07:38:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA19509 for current-outgoing; Fri, 11 Oct 1996 07:38:26 -0700 (PDT) Received: from bmccane.uit.net ([208.129.189.48]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA19493; Fri, 11 Oct 1996 07:38:18 -0700 (PDT) Received: (from root@localhost) by bmccane.uit.net (8.7.6/8.7.3) id JAA01225; Fri, 11 Oct 1996 09:38:04 -0500 (CDT) Date: Fri, 11 Oct 1996 09:38:03 -0500 (CDT) From: Wm Brian McCane To: Julian Elischer cc: current@freefall.freebsd.org Subject: Re: HELP!! kernel deadlock found.. In-Reply-To: <199610030539.WAA02269@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 2 Oct 1996, Julian Elischer wrote: > > Take the following 3 processes: > > proc N, with a lock on file / (inode 2) > wchan of that inode, waitstring of "ufslk2" > is waiting for inode for /mnt in the root filesystem (inode M) > > proc N+1 with a lock on the inode M (/mnt in root filesystem) > is waiting for inode for / (inode 2) in the mounted filesystem /mnt > it is showing "uihget" as a waitstring. > > proc N+2 with a lock on inode 2 of the mnt filesystem (/ of that filesystem) > is waiting for the inode for / and is showing "ufslk2" as a waitstring. > > It is my suspicion that process N+2 may be trying to unmount /mnt. > > Unfortunatly though I have the system stopped in gdb > I don't know how to examine the stacktrace of arbitrary > processes so I can't say how those 3 processes got where > they are. All other processes on the system > that need to access the filesystem are locked in "ufslk2" > > e.g. any new logins go there immediatly. :( > > if anyone knows how to examine an arbitrary process stacktrace > I'd like to hear about it....... > > I'll leave the system frozen in this state, > and I can arange to get other people with internet access > to be able to run gdb and examine whatever they want.. > > David? > Terry? > John? > any takers? > > I'd love to be able to see what those 3 stack traces show..... > > > julian > I am seeing a strange "lockup" on my system as well. After running for an unspecified length of time, I will see that 'innd' is in ufslk2. After it does this, the 'df' command gets stuck in vfsbsy, down in vfs_subr.c. The only way to fix this problem is to reboot the system, which I can do from the root account no problem. Another "interesting" side effect, is that any files which are written after this time end up 0 bytes long after the 'fsck' on system reboot. I discovered this when I rebuilt and installed a new kernel one time 8(. brian