From owner-freebsd-smp  Sun Aug 29  9:16:41 1999
Delivered-To: freebsd-smp@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2])
	by hub.freebsd.org (Postfix) with ESMTP id AB4D6156F6
	for <freebsd-smp@FreeBSD.ORG>; Sun, 29 Aug 1999 09:16:39 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id JAA06121;
	Sun, 29 Aug 1999 09:14:01 -0700 (PDT)
	(envelope-from dillon)
Date: Sun, 29 Aug 1999 09:14:01 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199908291614.JAA06121@apollo.backplane.com>
To: Suresh Rajagopalan <sraja@cinenet.net>
Cc: freebsd-smp@FreeBSD.ORG
Subject: Re: SMP freezes on 3.2-STABLE
References:  <Pine.GSO.3.96.990828234142.11606A-100000@hermosa.cinenet.net>
Sender: owner-freebsd-smp@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


:I've been trying to track down continual freezes on 3 servers running
:3.2-STABLE.   
:
:The machines are very busy web servers and simply freeze randomly after
:2-5 days of uptime.   There is no response from the console at
:the point of freeze.  I cannot get it to dump core either.   
:
:Machines are PIII-450 on ASUS P2B-D motherboards with 256Mb of RAM & 800M 
:swap. All machines are NFS clients mounting off a Solaris X86 server.
:The output of mptable is attached below.  I've tried MP 1.4 as well as
:1.1.
:
:I don't know if this is a problem with 3.x in general, and I have read
:about larger sites like yahoo running smp-stable.  If some of you are
:running SMP in a busy web/nfs enviroment, I'd love to hear from you.   
:
:Any help is appreciated.
:
:-Suresh

    Is this 3.x-STABLE or 3.2-RELEASE?

    Did you compile up a kernel with DDB support configured?  (i.e. to be 
    able to ctl-alt-esc into ddb from the console)?

    None of the currently known NFS related bugs freeze up the machine to
    the point where ctl-alt-esc fails to break into DDB.

    I would recommend recompiling the kernel for one of the machines to
    the absolute latest -STABLE (making sure DDB support has been configured),
    and the other one to the absolute latest -STABLE, with DDB, but without
    SMP, then see if none, one, or both machines crash.

    If when a machine freezes up you are able to escape into DDB, run the
    'trace' command and the 'ps' command prio to 'panic'ing the machine.

    Also, post the 'dmesg' output from the boot (cat /var/run/dmesg.boot).

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message