From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 08:08:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C60816A4CE; Tue, 6 Jan 2004 08:08:19 -0800 (PST) Received: from catwoman.cs.moravian.edu (catwoman.cs.moravian.edu [204.186.193.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6830A43D31; Tue, 6 Jan 2004 08:08:17 -0800 (PST) (envelope-from flash@cs.moravian.edu) Received: (from flash@localhost) by catwoman.cs.moravian.edu (8.11.7+Sun/8.9.3) id i06G8Gq14706; Tue, 6 Jan 2004 11:08:16 -0500 (EST) From: Stephen Corbesero Message-Id: <200401061608.i06G8Gq14706@catwoman.cs.moravian.edu> To: grog@freebsd.org (Greg 'groggy' Lehey) Date: Tue, 6 Jan 2004 11:08:16 -0500 (EST) In-Reply-To: <20040106015433.GU7617@wantadilla.lemis.com> from "Greg 'groggy' Lehey" at Jan 06, 2004 12:24:33 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: is vinum in current working for anyone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2004 16:08:19 -0000 Greg, et al. Thanks for all the responses. Here is a status update. I have made an important discovery. I now load load vinum via loader.conf as recommended (but not yet required) by the vinum document. My vinum on my ide drives now seems to load just fine. I will be doing some stress testing today. So, the problem I reported seems to letting vinum load via rc.conf and the /etc/rc.d/vinum script. > > On Monday, 5 January 2004 at 11:51:06 -0500, Stephen Corbesero wrote: > > > > I have been unable to use vinum in current since about 5.1. I have > > just sent debugging information to Greg Lehey, but I was wondering > > if it is working for anyone and how our configurations differ. > > > > If rc.conf specifies vinum_start="YES", my system usually crashes as > > soon as vinum loads and starts scanning disks. Sometimes it doesn't > > crash, but the vinum config is lost on at least one of the vinum > > drives. > > Yes, I have your backtrace, and I've been trying to make sense of it. > In the meantime I've had another one; together they give me the > feeling that something has gone funny just recently. I don't > understand from the backtrace how anything should have got trashed on > disk, though; I suspect that the data really was still there, and a > (the) bug gave the impression that it wasn't. > > This all worked perfectly on my test system a couple of days ago. I'm > currently updating my test box to the absolute latest (unfortunately, > that'll take a few hours), and I'll see if I can reproduce the problem > here. If not, I'll take up your offer of access to the box. > > FWIW, the problem *appears* to be in the inline function > __curthread(), called from init_drive. In the other dump, init_drive > has been passed an invalid drive name pointer (which "can't happen"), > and there's no reason to think that there's anything wrong in > __curthread (only one instruction). My current guess is that gdb is > lying about the location of the problem. > -- Stephen Corbesero Associate Professor of Computer Science Moravian College, Bethlehem, PA 18018