From owner-freebsd-bugs Mon May 8 00:06:28 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA20730 for bugs-outgoing; Mon, 8 May 1995 00:06:28 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA20715 for ; Mon, 8 May 1995 00:06:26 -0700 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id AAA01186; Mon, 8 May 1995 00:09:27 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id AAA00158; Mon, 8 May 1995 00:06:24 -0700 Message-Id: <199505080706.AAA00158@corbin.Root.COM> To: Steven Wallace cc: freebsd-bugs@FreeBSD.org Subject: Re: freeze up In-reply-to: Your message of "Sun, 07 May 95 23:07:37 PDT." <9505080607.AA03672@newport.ece.uci.edu> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 08 May 1995 00:06:22 -0700 Sender: bugs-owner@FreeBSD.org Precedence: bulk >So I found this experience very odd because existing processes continued >to run fine until they ran into something that blocked them from continuing >anymore while new commands (ls, kill, ps I tried) would freeze right >away - until I terminated this cc process. Any ideas on what this could >be? What should I do if I experience this freeze with a partial lock-up? Sounds like a vnode locking problem that eventually leads to locking the root directory (at which point your dead). I don't know what could be causing it, though. wcarchive is running -current from about 3 days ago and has been up running fine since (and this is with 250-300 users and mild paging) and I haven't seen the problem on my own machines. We did have problems like this a month or so ago, but the causes of those have been fixed. As far as what to do next time it happens...hmmm, if you can get to the console vty, you could escape to the debugger and do a 'ps' to find out what the processes are all sleeping on. Since your windows appear to still be mostly alive, you might try typing "ctrl-T" and noting the wmesg (the part in brackets that comes after the PID). This would provide more clues, perhaps. -DG