From owner-freebsd-current  Fri Mar 31  9:52: 8 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id BFAC037B52C
	for <current@FreeBSD.ORG>; Fri, 31 Mar 2000 09:52:06 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id JAA29716;
	Fri, 31 Mar 2000 09:52:06 -0800 (PST)
	(envelope-from dillon)
Date: Fri, 31 Mar 2000 09:52:06 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003311752.JAA29716@apollo.backplane.com>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Systems Administrator <geniusj@ods.org>,
	Greg Lehey <grog@lemis.com>, current@FreeBSD.ORG
Subject: Re: NFS/Vinum problems
References: <Pine.BSF.4.10.10003311007140.28524-100000@ods.org> <200003311747.JAA29684@apollo.backplane.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

::Jason DiCioccio

    Another possibility -- could you post your 'dmesg' output?  One thing
    that NFS does do is severely exercise both the network and the SCSI
    device in a concurrent fashion.

    If you happen to be using an NCR SCSI chipset, that could be the cause
    of the problem (though I have never in my life seen the panic message
    you posted in relation to the NCR cards).

    If you can get the panic regularly then it may be worthwhile trying to
    get some more information out of it.  If you compile up a kernel with
    the DDB option and your console is not running X, then the kernel will
    drop into DDB on the console when it panics and allow you to do a
    stack 'trace'.  You may also be able to then dump the machine by typing
    'panic' manually at the ddb prompt after copying down the trace
    information.

						-Matt



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