From owner-freebsd-questions Thu Oct 26 12:36:45 2000 Delivered-To: freebsd-questions@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 5255837B479; Thu, 26 Oct 2000 12:36:41 -0700 (PDT) Received: from slave (Studded@slave [10.0.0.1]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id MAA15519; Thu, 26 Oct 2000 12:36:19 -0700 (PDT) (envelope-from DougB@gorean.org) Date: Thu, 26 Oct 2000 12:36:18 -0700 (PDT) From: Doug Barton X-Sender: doug@dt051n37.san.rr.com To: Eric Brueggmann Cc: freebsd-questions@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: df -h In-Reply-To: <20001026072311.A765@snoopie.yi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 26 Oct 2000, Eric Brueggmann wrote: > Hello again, > > I'm experiencing some more df problems. I just typed "df -h" for the > second time in the past 2 days, and the machine rebooted. No messages in the > logs, nothing. That's really bad. Could you take a look at the instructions for setting up kernel debugging in the handbook (dumpdev in /etc/rc.conf*, etc.) and add the following to your kernel config: # Add extra debugging information to the kernel options DIAGNOSTIC # The INVARIANTS option is used in a number of source files to enable # extra sanity checking of internal structures. options INVARIANTS options INVARIANT_SUPPORT # Kernel debugger options DDB # Don't drop into DDB for a panic. Intended for unattended operation # where you may want to drop to DDB from the console, but still want # the machine to recover from a panic options DDB_UNATTENDED The last option is only necessary if you are concerned about this happening when you are not at the console. It would actually be better to leave this out if you are going to have physical access to the machine. Assuming that you can actually get information out of DDB, please send it to freebsd-stable@freebsd.org. I realize that this is a lot of work for you, but really it's the only way we can get the data we need to trace the problem. I alias df to 'df -h' on all my machines, running many vintages of RELENG_4 and RELENG_5, and I've never seen this panic, which is why I think the stack trace of a dead kernel is our only option here. Doug -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message