Date: Tue, 6 Jan 2004 11:08:16 -0500 (EST) From: Stephen Corbesero <flash@cs.moravian.edu> To: grog@freebsd.org (Greg 'groggy' Lehey) Cc: freebsd-current@freebsd.org Subject: Re: is vinum in current working for anyone Message-ID: <200401061608.i06G8Gq14706@catwoman.cs.moravian.edu> In-Reply-To: <20040106015433.GU7617@wantadilla.lemis.com> from "Greg 'groggy' Lehey" at Jan 06, 2004 12:24:33 PM
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401061608.i06G8Gq14706>