From owner-freebsd-stable Thu May 13 16: 2:58 1999 Delivered-To: freebsd-stable@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 37FDB1532B for ; Thu, 13 May 1999 16:02:56 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id QAA21251; Thu, 13 May 1999 16:02:45 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id QAA16527; Thu, 13 May 1999 16:02:43 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id QAA05755; Thu, 13 May 1999 16:02:42 -0700 (PDT) From: Don Lewis Message-Id: <199905132302.QAA05755@salsa.gv.tsc.tdk.com> Date: Thu, 13 May 1999 16:02:42 -0700 In-Reply-To: Cliff Skolnick "deadlock problem related to MFS & paging?" (May 13, 2:36pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Cliff Skolnick , freebsd-stable@FreeBSD.ORG Subject: Re: deadlock problem related to MFS & paging? Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On May 13, 2:36pm, Cliff Skolnick wrote: } Subject: deadlock problem related to MFS & paging? } } >From an offlist email exchange with Cy, it seem that Cy and myself are both } mounting /tmp with mount_mfs. We are also both locking up when the system is } doing IO in general, paging, and lots of I/O to /tmp. I'm wondering if } there is an interaction with the MFS code. } } I hope this is the case, and that removing the mount_mfs will stop the } lockups. This would explain why more people are not having the same } problem. } } Is anyone having these deadlocks not running MFS? Our news server wedged a couple days ago after running for a couple weeks. The code dated from about May 1, which was before the latest fix (attempt?). We are not using MFS on that machine. In our case, it was not a total lockup. There were three processes stuck in the inode state (syncer, innd, and *grep*). Before the May 1 software upgrade, we were running an old version of 3.0 from late last year. It was completely stable and had months of uptime. In addition to upgrading to more current code, we also started using vinum. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message