is vinum in current working for anyone

[Stephen Corbesero]

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