From owner-freebsd-smp Sun Nov 8 10:59:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA07924 for freebsd-smp-outgoing; Sun, 8 Nov 1998 10:59:07 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from marvin.ece.utexas.edu (marvin.ece.utexas.edu [128.83.52.151]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA07919 for ; Sun, 8 Nov 1998 10:59:05 -0800 (PST) (envelope-from bgrayson@marvin.ece.utexas.edu) Received: (from bgrayson@localhost) by marvin.ece.utexas.edu (8.8.8/8.8.8) id MAA04500; Sun, 8 Nov 1998 12:58:50 -0600 (CST) Message-ID: <19981108125850.B4167@marvin.ece.utexas.edu> Date: Sun, 8 Nov 1998 12:58:50 -0600 From: "Brian C. Grayson" To: David G Andersen , Kevin Van Maren Cc: freebsd-smp@FreeBSD.ORG Subject: Re: disk-wait problems/hangs References: <199811080638.XAA21120@fast.cs.utah.edu> <199811081835.LAA16723@lal.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: <199811081835.LAA16723@lal.cs.utah.edu>; from David G Andersen on Sun, Nov 08, 1998 at 11:35:53AM -0700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Nov 08, 1998 at 11:35:53AM -0700, David G Andersen wrote: > We've been experiencing the same problems; on this end, it looked like the > problem was possibly related to amd/nfs. We're running in a NIS > environment with heavy AMD and NFS usage; disabling things like SMP didn't > solve the problem, but disabling AMD did. Our solution was to back AMD > out to the pre-aug-23 integration of the a16 version; another person has > upgraded theirs to the latest b1 release. (We tried the upgrade, but it > didn't solve the problem). We are not running amd on these machines -- only NFS and NIS. FWIW, I've noticed that on other machines running NetBSD, amd-6.0a16 misbehaves (or just plain doesn't work!), so it's not just FreeBSD (not surprising), and it's not just SMP. 6.0a13 works fine for us, and NetBSD skipped over a14 and a15, I believe. > We're trying to get a crashdump of the hang, but after the AMD backout, > it's become difficult to reproduce. Are you sure it's a real hang? Once, ypbind got stuck in 'D', which meant that just about everything was impossible to do (no more logins, "ls" hangs, etc.). To verify, log in as root on another tty before initiating the netscape. Also, never run any command without backgrounding it, otherwise if that command gets hung in 'D', your tty is unusable, as things in 'D' don't catch signals. In other words, "ls &", "df &", "ps -ax &". The output is messy, but that's the price for keeping the tty alive! Our machine doesn't really hang, it's just that more and more processes go into 'D' and stay there. Eventually one runs out of ttys, and a critical daemon gets stuck in 'D'. Maybe if we were doing something more intensive than a single interactive shell, it would cause a hang! Brian -- Student: "How is Q(x,0) defined at x = 0?" Ken Richardson: "Just blow off 0." (about a function in Math 381 that is 0 for x<0, 1 for x>0) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message