From owner-freebsd-bugs@FreeBSD.ORG Mon Dec 1 20:40:18 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B9F516A4CE for ; Mon, 1 Dec 2003 20:40:18 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3423443FBF for ; Mon, 1 Dec 2003 20:40:17 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hB24eGFY006579 for ; Mon, 1 Dec 2003 20:40:16 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hB24eGsH006578; Mon, 1 Dec 2003 20:40:16 -0800 (PST) (envelope-from gnats) Date: Mon, 1 Dec 2003 20:40:16 -0800 (PST) Message-Id: <200312020440.hB24eGsH006578@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Russell Cattelan Subject: Re: kern/59878: vinum panics 5.1 system X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Russell Cattelan List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2003 04:40:18 -0000 The following reply was made to PR kern/59878; it has been noted by GNATS. From: Russell Cattelan To: "Greg 'groggy' Lehey" Cc: Russell Cattelan , FreeBSD-gnats-submit@FreeBSD.org Subject: Re: kern/59878: vinum panics 5.1 system Date: Mon, 01 Dec 2003 22:27:20 -0600 On Mon, 2003-12-01 at 16:43, Greg 'groggy' Lehey wrote: > On Monday, 1 December 2003 at 15:15:23 -0600, Russell Cattelan wrote: > >> How-To-Repeat: > > It's unclear exactly what is going on but bk was being run each time the > > system went down. > > What's bk? BitKeeper. This vinum/ufs filesystem was from a running 4.9 system that was upgraded to 5.1, so I don't know if that has anything to do with it. The system itself is fairly straight forward dual 266 with 128meg of ram. The kernel was compiled from the cvs tree checked out with the 5.1 release tag. The console serial line was not connected at the time of the panic so the actually panic string did not show up. I'll make sure to grab that the next time the panic happens. Just wanted to file this as a place holder for now since this happened twice in 2 days something must be a muck. > > You don't even state the panic string. Please supply the information > requested in the man page and on the web site > (http://www.vinumvm.org/vinum/how-to-debug.html): > > * What problems are you having? > * Which version of FreeBSD are you running? > * Have you made any changes to the system sources, including > Vinum? > > * Supply the output of the vinum list command. If you can't start > Vinum, supply the on-disk configuration, as described below. If > you can't start Vinum, then (and only then) send a copy of the > configuration file. > > * Supply an extract of the Vinum history file. Unless you have > explicitly renamed it, it will be /var/log/vinum_history. This > file can get very big; please limit it to the time around when > you have the problems. Each line contains a timestamp at the > beginning, so you will have no difficulty in establishing which > data is of relevance. > > * Supply an extract of the file /var/log/messages. Restrict the > extract to the same time frame as the history file. Again, each > line contains a timestamp at the beginning, so you will have no > difficulty in establishing which data is of relevance. > > * If you have a crash, please supply a backtrace from the dump > analysis as discussed below under Kernel Panics. Please don't > delete the crash dump; it may be needed for further analysis. > > What not to supply > > Please don't supply the following information unless I ask for it: > > * The output of the vinum printconfig command. > * Your Vinum configuration file, unless your problem is that you > can't start Vinum at all. > * Your dmesg output. > * Your kernel configuration file. > * Processor dumps. > > In this case, it looks as if it could be a memory depletion problem. > How much memory does the system have? > > Greg > -- > See complete headers for address and phone numbers. -- Russell Cattelan