From owner-freebsd-hackers Sun Mar 5 20:11:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id E9A7E37BC00 for ; Sun, 5 Mar 2000 20:11:35 -0800 (PST) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id XAA23516; Sun, 5 Mar 2000 23:11:03 -0500 (EST) Message-Id: <200003060411.XAA23516@cs.rpi.edu> To: dillon@backplane.com Cc: freebsd-hackers@freebsd.org, crossd@cs.rpi.edu Subject: vmpfw, again... Date: Sun, 05 Mar 2000 23:11:03 -0500 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have 2 cores from machines in the aforementioned state. What should I do? For those not playing at home, it appears there is some sort of deadlock situation in the NFS or VM system. The indication of this is a process that blocks in 'vmpfw' for no apparent reason. All other transactions to that same filesystem continue per normal. A specific interaction to that same file will block. For example say that 'emacs' has entered the 'vmpfw' state, other transactions to the same FS will continue unimpeded, but 'cat emacs >/dev/null' will also enter eternal disk-wait without ever any kernel messages. -- David Cross | email: crossd@cs.rpi.edu Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message