Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Sep 1999 13:05:35 -0400 (EDT)
From:      Brad Chisholm <sasblc@unx.sas.com>
To:        grog@lemis.com (Greg Lehey)
Cc:        sasblc@unx.sas.com (Brad Chisholm), freebsd-current@FreeBSD.ORG
Subject:   Re: System crash on "vinum start"
Message-ID:  <199909271705.NAA43302@concours.pc.sas.com>
In-Reply-To: <19990925104024.B54407@freebie.lemis.com> from Greg Lehey at "Sep 25, 1999 10:40:24 am"

next in thread | previous in thread | raw e-mail | index | archive | help
> > I'm having a problem where the "vinum start" command crashes my system.
> > This happens regardless of whether it's being issued during bootup via
> > /etc/rc or from the command line on a running system.
> >
> > Interestingly, however, if I issue the start command from the vinum
> > interactive prompt, it works properly with no crash.
> >
> > I'm currently running on a snap built this morning (0924), but it was
> > also happening on a snap from 0914.
> >
> > Crash info, vinum config, and disk info are below.  Let me know if I
> > can provide any additional information.
> 
> Yes.  Please read the instructions in vinum(4) about debugging panic
> dumps.
> 
> I found a minor bug in 'vinum start' recently, but I doubt it's
> causing your problem.  I'll commit it Real Soon Now.
> 

Well, I believe I discovered the source of my problem.  It turns out that 
I did not have the correct devices configured in /dev for the component 
drives.  I had da[0-3]e, but not da[0-3]s1e.  The documentation seemed to
indicate that the da?s1? devices were not required, but once I made them,
the crashes stopped.

It's interesting that I could bring the array up using the 'start'
command from the vinum interactive prompt, and things would work
properly with the missing devices, while issuing a direct 'vinum
start' would cause a panic.

Even though this may have been a stupid user error, it would be nice
if vinum could catch this without a system crash.  To that end, I'm
including an updated traceback from my panic dump which has the vinum
calls included.

Thanks for providing such a useful piece of software!

-Brad

-- Crash dump traceback --

(kgdb) bt
#0  boot (howto=0x100) at ../../kern/kern_shutdown.c:281
#1  0xc0169e80 in poweroff_wait (junk=0xc02fd44f, howto=0xc8af7180) at ../../kern/kern_shutdown.c:531
#2  0xc0272269 in trap_fatal (frame=0xc94f4b70, eva=0x48) at ../../i386/i386/trap.c:907
#3  0xc0271f41 in trap_pfault (frame=0xc94f4b70, usermode=0x0, eva=0x48) at ../../i386/i386/trap.c:800
#4  0xc0271beb in trap (frame={tf_fs = 0x10, tf_es = 0x10, tf_ds = 0x10, tf_edi = 0x0, tf_esi = 0x200, 
      tf_ebp = 0xc94f4be0, tf_isp = 0xc94f4b9c, tf_ebx = 0x0, tf_edx = 0x0, tf_ecx = 0x8, tf_eax = 0x0, 
      tf_trapno = 0xc, tf_err = 0x0, tf_eip = 0xc018b64b, tf_cs = 0x8, tf_eflags = 0x10246, tf_esp = 0xc94f4c50, 
      tf_ss = 0x200}) at ../../i386/i386/trap.c:426
#5  0xc018b64b in getblk (vp=0x0, blkno=0x8, size=0x1000, slpflag=0x0, slptimeo=0x0) at ../../kern/vfs_bio.c:2109
#6  0xc018995a in bread (vp=0x0, blkno=0x8, size=0x1000, cred=0x0, bpp=0xc94f4c50) at ../../kern/vfs_bio.c:477
#7  0xc0d65fcf in read_drive (drive=0xc0e28800, buf=0xc0e29000, length=0x20000, offset=0x1200)
    at /usr/src/sys/modules/vinum/../../dev/vinum/vinumio.c:284
#8  0xc0d67072 in vinum_scandisk (devicename=0xc0d70b04, drives=0x5)
    at /usr/src/sys/modules/vinum/../../dev/vinum/vinumio.c:959
#9  0xc0d64e6d in parse_config (cptr=0xc0d59000 "read", keyset=0xc0d709d0, update=0x0)
    at /usr/src/sys/modules/vinum/../../dev/vinum/vinumconfig.c:1514
#10 0xc0d64ec7 in parse_user_config (cptr=0xc0d59000 "read", keyset=0xc0d709d0)
    at /usr/src/sys/modules/vinum/../../dev/vinum/vinumconfig.c:1557
#11 0xc0d6af94 in vinumioctl (dev=0xc0d56480, cmd=0xc4004640, data=0xc0d59000 "read", flag=0x3, p=0xc8af7180)
    at /usr/src/sys/modules/vinum/../../dev/vinum/vinumioctl.c:110
#12 0xc019dc47 in spec_ioctl (ap=0xc94f4e08) at ../../miscfs/specfs/spec_vnops.c:513
#13 0xc019d4bd in spec_vnoperate (ap=0xc94f4e08) at ../../miscfs/specfs/spec_vnops.c:124
#14 0xc023ef09 in ufs_vnoperatespec (ap=0xc94f4e08) at ../../ufs/ufs/ufs_vnops.c:2313
#15 0xc0197f20 in vn_ioctl (fp=0xc0d29100, com=0xc4004640, data=0xc0d59000 "read", p=0xc8af7180) at vnode_if.h:395
#16 0xc0176fcb in ioctl (p=0xc8af7180, uap=0xc94f4f80) at ../../sys/file.h:166
#17 0xc02724a6 in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi = 0x5, tf_esi = 0xbfbfc808, 
      tf_ebp = 0xbfbfcc08, tf_isp = 0xc94f4fd4, tf_ebx = 0x5, tf_edx = 0x808cc25, tf_ecx = 0xbfbfc839, tf_eax = 0x36, 
      tf_trapno = 0xc, tf_err = 0x2, tf_eip = 0x806bc0c, tf_cs = 0x1f, tf_eflags = 0x246, tf_esp = 0xbfbfc7e8, 
      tf_ss = 0x2f}) at ../../i386/i386/trap.c:1056
#18 0xc02654c6 in Xint0x80_syscall ()
#19 0x804cbc7 in ?? ()
#20 0x8048492 in ?? ()
#21 0x80482fd in ?? ()
#22 0x80480e9 in ?? ()


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909271705.NAA43302>