From nobody@FreeBSD.org  Mon May 21 05:03:20 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id E252A37B424
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 21 May 2001 05:03:19 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f4LC3Jw09598;
	Mon, 21 May 2001 05:03:19 -0700 (PDT)
	(envelope-from nobody)
Message-Id: <200105211203.f4LC3Jw09598@freefall.freebsd.org>
Date: Mon, 21 May 2001 05:03:19 -0700 (PDT)
From: conrad@th.physik.uni-bonn.de
To: freebsd-gnats-submit@FreeBSD.org
Subject: vinum crashed after 'vinum dumpconfig'
X-Send-Pr-Version: www-1.0

>Number:         27498
>Category:       misc
>Synopsis:       vinum crashed after 'vinum dumpconfig'
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    grog
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon May 21 05:10:01 PDT 2001
>Closed-Date:    Tue Jun 17 22:21:00 PDT 2003
>Last-Modified:  Tue Jun 17 22:21:00 PDT 2003
>Originator:     Jan Conrad
>Release:        FreeBSD 4.3R
>Organization:
Univ. Bonn, Germany
>Environment:
FreeBSD dirac.th.physik.uni-bonn.de 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Thu May  3 10:40:55 CEST 2001     admin@hamilton.th.physik.uni-bonn.de:/bsd/misc/src/sys/compile/DIRAC  i386
>Description:
While taring 4GB of data onto our newly newfs'd vinum filesystem, I
issued the command 'vinum dumpconfig'.

The first time it worked, the second time the system paniced and 
dumped core (with a page fault)!

Maybe it was just an accidential and has nothing to do with
'vinum dumpconfig', but the panic occured exactly when I hit enter -
there was no output anymore.

The vinum config is simply

drive d0 device /dev/da0s1a
drive d1 device /dev/da1s1a

volume share
  plex org striped 283k
    sd length 256m drive d0
    sd length 256m drive d1

volume secure
  plex org striped 283k
    sd length 256m drive d0
    sd length 256m drive d1

volume home
  plex org striped 283k
    sd length 0 drive d0
    sd length 0 drive d1

(gtar was on home, home is 33GB big)and works perfectly otherwise.
Home was mounted without softupdates

The coredump etc. is available

IdlePTD 3416064
initial pcb at 2b8f00
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xb7
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc0165fb0
stack pointer           = 0x10:0xce2dbbd4
frame pointer           = 0x10:0xce2dbbe8
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 415 (gtar)
interrupt mask          = none
trap number             = 12
panic: page fault

syncing disks... 

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xb7
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc0165fb0
stack pointer           = 0x10:0xce2db8a4
frame pointer           = 0x10:0xce2db8b8
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 415 (gtar)
interrupt mask          = bio 
trap number             = 12
panic: page fault
Uptime: 44m40s

dumping to dev #ad/0x20021, offset 1573024
dump ata2: resetting devices .. done
255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
---
#0  0xc015c746 in dumpsys () at ../../kern/kern_shutdown.c:469
469             if (dumping++) {

>How-To-Repeat:
Sorry, the machine is our main server and I could not afford to try
again.
Without the 'vinum dumpconfig' everything worked fine... (but with 
softupdates this time)
>Fix:
unknown
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->grog 
Responsible-Changed-By: dwmalone 
Responsible-Changed-When: Mon May 21 05:53:13 PDT 2001 
Responsible-Changed-Why:  
I tried to reproduce the problem here on a machine and I think I managed 
to (tared /usr to the vinum disk and kept doing "vinum dumpconfig"), so 
it looks easy enough to reproduce. Grog is likely to have a better idea 
of what the problem is, but if you could rerun gdb on the vmcore and 
send us the output of "trace" it would probably help. 

(I'll try to get a trace from the machine I just killed once I'm closer 
to it). 

David. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27498 

From: Jan Conrad <conrad@th.physik.uni-bonn.de>
To: <dwmalone@FreeBSD.org>
Cc: <freebsd-gnats-submit@FreeBSD.org>, <grog@FreeBSD.org>,
	<dwmalone@maths.tcd.ie>
Subject: Re: misc/27498: vinum crashed after 'vinum dumpconfig'
Date: Mon, 21 May 2001 17:20:06 +0200 (CEST)

 On Mon, 21 May 2001 dwmalone@FreeBSD.org wrote:
 
 > I tried to reproduce the problem here on a machine and I think I managed
 > to (tared /usr to the vinum disk and kept doing "vinum dumpconfig"), so
 > it looks easy enough to reproduce. Grog is likely to have a better idea
 > of what the problem is, but if you could rerun gdb on the vmcore and
 > send us the output of "trace" it would probably help.
 >
 > (I'll try to get a trace from the machine I just killed once I'm closer
 > to it).
 
 I suppose you mean a 'bt' stack trace - here it comes
 
 
 ......
 #0  0xc015c746 in dumpsys () at ../../kern/kern_shutdown.c:469
 469             if (dumping++) {
 (kgdb) bt
 #0  0xc015c746 in dumpsys () at ../../kern/kern_shutdown.c:469
 #1  0xc1282894 in ?? ()
 #2  0xc015c567 in boot (howto=260) at ../../kern/kern_shutdown.c:312
 #3  0xc015c8e4 in poweroff_wait (junk=0xc028ca0f, howto=-836072832)
     at ../../kern/kern_shutdown.c:573
 #4  0xc0251529 in dblfault_handler () at ../../i386/i386/trap.c:972
 #5  0xc0251201 in trap_pfault (frame=0xce2db864, usermode=0, eva=183)
     at ../../i386/i386/trap.c:851
 #6  0xc0250dbb in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
       tf_edi = 32644375, tf_esi = -1, tf_ebp = -835864392,
       tf_isp = -835864432, tf_ebx = 2, tf_edx = 2, tf_ecx = -1049224672,
       tf_eax = -1049224672, tf_trapno = 12, tf_err = 0, tf_eip =
 -1072275536,
       tf_cs = 8, tf_eflags = 66182, tf_esp = -1054445344, tf_ss =
 -1049224672})
     at ../../i386/i386/trap.c:478
 #7  0xc0165fb0 in dscheck (bp=0xc1761a20, ssp=0xc160a300)
     at ../../kern/subr_diskslice.c:198
 #8  0xc0165c29 in diskioctl (dev=0xc1761a20, cmd=3241481856,
     data=0xc1283b98 "home", fflag=-1047516224, p=0xc6534eec)
     at ../../kern/subr_disk.c:210
 #9  0xc12987a3 in ?? ()
 #10 0xc129849e in ?? ()
 #11 0xc1298306 in ?? ()
 #12 0xc0191230 in spec_freeblks (ap=0xce2db970)
     at ../../miscfs/specfs/spec_vnops.c:499
 #13 0xc0190c6d in spec_open (ap=0xce2db970)
     at ../../miscfs/specfs/spec_vnops.c:147
 #14 0xc0211e15 in default_pager_alloc (handle=0xce2db970, size=7622315756,
     prot=6865984, offset=-3589830144918201952) at
 ../../vm/default_pager.c:82
 #15 0xc0211775 in ufs_print (ap=0xce2db9b4) at
 ../../ufs/ufs/ufs_vnops.c:1804
 #16 0xc0211de5 in ufs_vnoperatespec (ap=0xce2db9b4)
     at ../../ufs/ufs/ufs_vnops.c:2390
 #17 0xc017e50a in bwrite (bp=0xc6534eec) at ../../kern/vfs_bio.c:264
 #18 0xc01839da in vop_sharedlock (ap=0xce2dba18)
     at ../../kern/vfs_default.c:354
 #19 0xc0183835 in vop_panic (ap=0xce2dba18) at
 ../../kern/vfs_default.c:146
 #20 0xc0211de5 in ufs_vnoperatespec (ap=0xce2dba18)
     at ../../ufs/ufs/ufs_vnops.c:2390
 #21 0xc017f43a in getnewbuf (slpflag=-967618836, slptimeo=-833333632,
     size=-1070806560, maxsize=-833681600) at ../../kern/vfs_bio.c:1503
 #22 0xc020b44d in ffs_fsync (ap=0xce2dba7c) at
 ../../ufs/ffs/ffs_vnops.c:226
 #23 0xc0209e77 in ffs_sync (mp=0xc141c800, waitfor=2, cred=0xc0a3c900,
     p=0xc02cc9e0) at ../../ufs/ffs/ffs_vfsops.c:980
 #24 0xc0188537 in sync (p=0xc02cc9e0, uap=0x0) at
 ../../kern/vfs_syscalls.c:564
 #25 0xc015c33a in boot (howto=256) at ../../kern/kern_shutdown.c:241
 #26 0xc015c8e4 in poweroff_wait (junk=0xc028ca0f, howto=-836072832)
     at ../../kern/kern_shutdown.c:573
 #27 0xc0251529 in dblfault_handler () at ../../i386/i386/trap.c:972
 #28 0xc0251201 in trap_pfault (frame=0xce2dbb94, usermode=0, eva=183)
     at ../../i386/i386/trap.c:851
 #29 0xc0250dbb in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
       tf_edi = 9694471, tf_esi = -1, tf_ebp = -835863576, tf_isp =
 -835863616,
       tf_ebx = 20, tf_edx = 2, tf_ecx = -1055021536, tf_eax = -1055021536,
       tf_trapno = 12, tf_err = 0, tf_eip = -1072275536, tf_cs = 8,
       tf_eflags = 66182, tf_esp = -1054445344, tf_ss = -1055021536})
 ---Type <return> to continue, or q <return> to quit---
     at ../../i386/i386/trap.c:478
 #30 0xc0165fb0 in dscheck (bp=0xc11da620, ssp=0xc160a300)
     at ../../kern/subr_diskslice.c:198
 #31 0xc0165c29 in diskioctl (dev=0xc11da620, cmd=3241481856,
     data=0xc1283b98 "home", fflag=-1047524096, p=0xc64f88c0)
     at ../../kern/subr_disk.c:210
 #32 0xc12987a3 in ?? ()
 #33 0xc129849e in ?? ()
 #34 0xc1298306 in ?? ()
 #35 0xc0191230 in spec_freeblks (ap=0xce2dbca0)
     at ../../miscfs/specfs/spec_vnops.c:499
 #36 0xc0190c6d in spec_open (ap=0xce2dbca0)
     at ../../miscfs/specfs/spec_vnops.c:147
 #37 0xc0211e15 in default_pager_alloc (handle=0xce2dbca0, size=7622068416,
     prot=0, offset=-3589830144918201952) at ../../vm/default_pager.c:82
 #38 0xc0211775 in ufs_print (ap=0xce2dbce4) at
 ../../ufs/ufs/ufs_vnops.c:1804
 #39 0xc0211de5 in ufs_vnoperatespec (ap=0xce2dbce4)
     at ../../ufs/ufs/ufs_vnops.c:2390
 #40 0xc017e50a in bwrite (bp=0xc64f88c0) at ../../kern/vfs_bio.c:264
 #41 0xc01839da in vop_sharedlock (ap=0xce2dbd20)
     at ../../kern/vfs_default.c:354
 #42 0xc0183835 in vop_panic (ap=0xce2dbd20) at
 ../../kern/vfs_default.c:146
 #43 0xc0211de5 in ufs_vnoperatespec (ap=0xce2dbd20)
     at ../../ufs/ufs/ufs_vnops.c:2390
 #44 0xc017e84e in bowrite (bp=0xc64f88c0) at vnode_if.h:1191
 #45 0xc01830f7 in cluster_wbuild () at ../../kern/vfs_cluster.c:884
 #46 0xc0182c0e in cluster_write (bp=0xc654d548, filesize=7340032,
 seqcount=127)
     at ../../kern/vfs_cluster.c:669
 #47 0xc020ad2a in ffs_write (ap=0xce2dbe68)
     at ../../ufs/ufs/ufs_readwrite.c:517
 #48 0xc018d1cc in vn_write (fp=0xc176d9c0, uio=0xce2dbed8,
 cred=0xc1406980,
     flags=0, p=0xce2a8a80) at ../../kern/vfs_vnops.c:388
 #49 0xc016a751 in dofilewrite (p=0xce2a8a80, fp=0xc176d9c0, fd=3,
     buf=0x80a0000, nbyte=10240, offset=-1, flags=0)
     at ../../kern/sys_generic.c:409
 #50 0xc016a60a in write () at ../../kern/sys_generic.c:332
 #51 0xc02517d5 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
       tf_edi = 134873088, tf_esi = 10240, tf_ebp = -1077937668,
       tf_isp = -835862572, tf_ebx = 134873088, tf_edx = 3, tf_ecx = 0,
       tf_eax = 4, tf_trapno = 7, tf_err = 2, tf_eip = 134746012, tf_cs =
 31,
       tf_eflags = 659, tf_esp = -1077937712, tf_ss = 47})
     at ../../i386/i386/trap.c:1161
 #52 0xc02459b5 in fork_trampoline ()
 #53 0x80524aa in ?? ()
 #54 0x8054541 in ?? ()
 #55 0x805a7fe in ?? ()
 #56 0x8048135 in ?? ()
 
 
 
 >
 > 	David.
 >
 > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27498
 >
 > To Unsubscribe: send mail to majordomo@FreeBSD.org
 > with "unsubscribe freebsd-bugs" in the body of the message
 >
 
 -- 
 Physikalisches Institut der Universitaet Bonn
 Nussallee 12
 D-53115 Bonn
 GERMANY
 

From: Greg Lehey <grog@lemis.com>
To: Jan Conrad <conrad@th.physik.uni-bonn.de>
Cc: dwmalone@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org,
	dwmalone@maths.tcd.ie
Subject: Re: misc/27498: vinum crashed after 'vinum dumpconfig'
Date: Tue, 22 May 2001 09:16:31 +0930

 On Monday, 21 May 2001 at 17:20:06 +0200, Jan Conrad wrote:
 > On Mon, 21 May 2001 dwmalone@FreeBSD.org wrote:
 >
 >> I tried to reproduce the problem here on a machine and I think I managed
 >> to (tared /usr to the vinum disk and kept doing "vinum dumpconfig"), so
 >> it looks easy enough to reproduce. Grog is likely to have a better idea
 >> of what the problem is, but if you could rerun gdb on the vmcore and
 >> send us the output of "trace" it would probably help.
 >>
 >> (I'll try to get a trace from the machine I just killed once I'm closer
 >> to it).
 >
 > I suppose you mean a 'bt' stack trace - here it comes
 
 Would you please follow the instructions in vinum(4) or
 http://www.vinumvm.org/ and repeat the backtrace.
 
 Greg
 --
 Finger grog@lemis.com for PGP public key
 See complete headers for address and phone numbers

From: Greg Lehey <grog@lemis.com>
To: dwmalone@FreeBSD.org
Cc: freebsd-bugs@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/27498: vinum crashed after 'vinum dumpconfig'
Date: Tue, 22 May 2001 16:14:15 +0930

 On Monday, 21 May 2001 at  5:59:56 -0700, dwmalone@FreeBSD.org wrote:
 > Synopsis: vinum crashed after 'vinum dumpconfig'
 >
 > Responsible-Changed-From-To: freebsd-bugs->grog
 > Responsible-Changed-By: dwmalone
 > Responsible-Changed-When: Mon May 21 05:53:13 PDT 2001
 > Responsible-Changed-Why:
 > I tried to reproduce the problem here on a machine and I think I managed
 > to (tared /usr to the vinum disk and kept doing "vinum dumpconfig"), so
 > it looks easy enough to reproduce. Grog is likely to have a better idea
 > of what the problem is, but if you could rerun gdb on the vmcore and
 > send us the output of "trace" it would probably help.
 
 Both of you: are you using devfs?  Currently, devfs limits the
 pathnames to 15 (!) characters, and doesn't seem to check them.  I've
 run into a number of problems as a result, but I couldn't get
 dumpconfig to do anything (after 2500 iterations!).
 
 If this is a devfs system, try this patch, then build a new kernel
 etc.
 
 --- param.h     2001/02/24 10:44:03     1.91
 +++ param.h     2001/05/22 05:13:16
 @@ -74,7 +74,7 @@
  #define        NOFILE          OPEN_MAX        /* max open files per process */
  #define        NOGROUP         65535           /* marker for empty group set member */
  #define MAXHOSTNAMELEN 256             /* max hostname size */
 -#define SPECNAMELEN    15              /* max length of devicename */
 +#define SPECNAMELEN    96              /* max length of devicename */
  
  /* More types and definitions used throughout the kernel. */
  #ifdef _KERNEL
 
 Greg
 --
 Finger grog@lemis.com for PGP public key
 See complete headers for address and phone numbers

From: David Malone <dwmalone@maths.tcd.ie>
To: Greg Lehey <grog@lemis.com>
Cc: freebsd-bugs@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org,
	conrad@th.physik.uni-bonn.de
Subject: Re: misc/27498: vinum crashed after 'vinum dumpconfig' 
Date: Tue, 22 May 2001 09:09:46 +0100

 > Both of you: are you using devfs?
 
 Nope - the machine I crashed was running a relatively recent 4.X.
 I still haven't been close enough to it to see exactly what the
 panic was.
 
 	David.

From: Jan Conrad <conrad@th.physik.uni-bonn.de>
To: Greg Lehey <grog@lemis.com>
Cc: <dwmalone@FreeBSD.org>, <freebsd-gnats-submit@FreeBSD.org>,
	<dwmalone@maths.tcd.ie>
Subject: Re: misc/27498: vinum crashed after 'vinum dumpconfig'
Date: Tue, 22 May 2001 10:45:27 +0200 (CEST)

 On Tue, 22 May 2001, Greg Lehey wrote:
 
 > On Monday, 21 May 2001 at 17:20:06 +0200, Jan Conrad wrote:
 > > On Mon, 21 May 2001 dwmalone@FreeBSD.org wrote:
 > >
 > >> I tried to reproduce the problem here on a machine and I think I managed
 > >> to (tared /usr to the vinum disk and kept doing "vinum dumpconfig"), so
 > >> it looks easy enough to reproduce. Grog is likely to have a better idea
 > >> of what the problem is, but if you could rerun gdb on the vmcore and
 > >> send us the output of "trace" it would probably help.
 > >>
 > >> (I'll try to get a trace from the machine I just killed once I'm closer
 > >> to it).
 > >
 > > I suppose you mean a 'bt' stack trace - here it comes
 >
 > Would you please follow the instructions in vinum(4) or
 > http://www.vinumvm.org/ and repeat the backtrace.
 
 ops - I am sorry - here it comes
 
 -Jan
 
 
 IdlePTD 3416064
 initial pcb at 2b8f00
 panicstr: page fault
 panic messages:
 ---
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0xb7
 fault code              = supervisor read, page not present
 instruction pointer     = 0x8:0xc0165fb0
 stack pointer           = 0x10:0xce2dbbd4
 frame pointer           = 0x10:0xce2dbbe8
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, def32 1, gran 1
 processor eflags        = interrupt enabled, resume, IOPL = 0
 current process         = 415 (gtar)
 interrupt mask          = none
 trap number             = 12
 panic: page fault
 
 syncing disks...
 
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0xb7
 fault code              = supervisor read, page not present
 instruction pointer     = 0x8:0xc0165fb0
 stack pointer           = 0x10:0xce2db8a4
 frame pointer           = 0x10:0xce2db8b8
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, def32 1, gran 1
 processor eflags        = interrupt enabled, resume, IOPL = 0
 current process         = 415 (gtar)
 interrupt mask          = bio
 trap number             = 12
 panic: page fault
 Uptime: 44m40s
 
 dumping to dev #ad/0x20021, offset 1573024
 dump ata2: resetting devices .. done
 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238
 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220
 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202
 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184
 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166
 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148
 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130
 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112
 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91
 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66
 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41
 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
 ---
 #0  0xc015c746 in dumpsys () at ../../kern/kern_shutdown.c:469
 469             if (dumping++) {
 (kgdb) bt
 #0  0xc015c746 in dumpsys () at ../../kern/kern_shutdown.c:469
 #1  0xc1282894 in ?? ()
 #2  0xc015c567 in boot (howto=0x104) at ../../kern/kern_shutdown.c:312
 #3  0xc015c8e4 in poweroff_wait (junk=0xc028ca0f, howto=0xce2a8a80) at
 ../../kern/kern_shutdown.c:573
 #4  0xc0251529 in dblfault_handler () at ../../i386/i386/trap.c:972
 #5  0xc0251201 in trap_pfault (frame=0xce2db864, usermode=0x0, eva=0xb7)
 at ../../i386/i386/trap.c:851
 #6  0xc0250dbb in trap (frame={tf_fs = 0x10, tf_es = 0x10, tf_ds = 0x10,
 tf_edi = 0x1f21d17, tf_esi = 0xffffffff,
       tf_ebp = 0xce2db8b8, tf_isp = 0xce2db890, tf_ebx = 0x2, tf_edx =
 0x2, tf_ecx = 0xc1761a20, tf_eax = 0xc1761a20,
       tf_trapno = 0xc, tf_err = 0x0, tf_eip = 0xc0165fb0, tf_cs = 0x8,
 tf_eflags = 0x10286, tf_esp = 0xc12670e0,
       tf_ss = 0xc1761a20}) at ../../i386/i386/trap.c:478
 #7  0xc0165fb0 in dscheck (bp=0xc1761a20, ssp=0xc160a300) at
 ../../kern/subr_diskslice.c:198
 #8  0xc0165c29 in diskioctl (dev=0xc1761a20, cmd=0xc1351680,
 data=0xc1283b98 "home", fflag=0xc1902bc0, p=0xc6534eec)
     at ../../kern/subr_disk.c:210
 #9  0xc12987a3 in launch_requests (rq=0xc1902bc0, reviveok=0x0)
     at /bsd/misc/src/sys/modules/vinum/../../dev/vinum/vinumrequest.c:431
 #10 0xc129849e in vinumstart (bp=0xc6534eec, reviveok=0x0)
     at /bsd/misc/src/sys/modules/vinum/../../dev/vinum/vinumrequest.c:291
 #11 0xc1298306 in vinumstrategy (bp=0xc6534eec) at
 /bsd/misc/src/sys/modules/vinum/../../dev/vinum/vinumrequest.c:164
 #12 0xc0191230 in spec_freeblks (ap=0xce2db970) at
 ../../miscfs/specfs/spec_vnops.c:499
 #13 0xc0190c6d in spec_open (ap=0xce2db970) at
 ../../miscfs/specfs/spec_vnops.c:147
 #14 0xc0211e15 in default_pager_alloc (handle=0xce2db970,
 size=0x1c6534eec, prot=0x68c440, offset=0xce2e5c80c02959a0)
     at ../../vm/default_pager.c:82
 #15 0xc0211775 in ufs_print (ap=0xce2db9b4) at
 ../../ufs/ufs/ufs_vnops.c:1804
 #16 0xc0211de5 in ufs_vnoperatespec (ap=0xce2db9b4) at
 ../../ufs/ufs/ufs_vnops.c:2390
 #17 0xc017e50a in bwrite (bp=0xc6534eec) at ../../kern/vfs_bio.c:264
 #18 0xc01839da in vop_sharedlock (ap=0xce2dba18) at
 ../../kern/vfs_default.c:354
 #19 0xc0183835 in vop_panic (ap=0xce2dba18) at
 ../../kern/vfs_default.c:146
 #20 0xc0211de5 in ufs_vnoperatespec (ap=0xce2dba18) at
 ../../ufs/ufs/ufs_vnops.c:2390
 #21 0xc017f43a in getnewbuf (slpflag=0xc6534eec, slptimeo=0xce545680,
 size=0xc02cc9e0, maxsize=0xce4f0740)
     at ../../kern/vfs_bio.c:1503
 #22 0xc020b44d in ffs_fsync (ap=0xce2dba7c) at
 ../../ufs/ffs/ffs_vnops.c:226
 #23 0xc0209e77 in ffs_sync (mp=0xc141c800, waitfor=0x2, cred=0xc0a3c900,
 p=0xc02cc9e0)
     at ../../ufs/ffs/ffs_vfsops.c:980
 #24 0xc0188537 in sync (p=0xc02cc9e0, uap=0x0) at
 ../../kern/vfs_syscalls.c:564
 #25 0xc015c33a in boot (howto=0x100) at ../../kern/kern_shutdown.c:241
 #26 0xc015c8e4 in poweroff_wait (junk=0xc028ca0f, howto=0xce2a8a80) at
 ../../kern/kern_shutdown.c:573
 #27 0xc0251529 in dblfault_handler () at ../../i386/i386/trap.c:972
 #28 0xc0251201 in trap_pfault (frame=0xce2dbb94, usermode=0x0, eva=0xb7)
 at ../../i386/i386/trap.c:851
 #29 0xc0250dbb in trap (frame={tf_fs = 0x10, tf_es = 0x10, tf_ds = 0x10,
 tf_edi = 0x93ed07, tf_esi = 0xffffffff,
       tf_ebp = 0xce2dbbe8, tf_isp = 0xce2dbbc0, tf_ebx = 0x14, tf_edx =
 0x2, tf_ecx = 0xc11da620, tf_eax = 0xc11da620,
       tf_trapno = 0xc, tf_err = 0x0, tf_eip = 0xc0165fb0, tf_cs = 0x8,
 tf_eflags = 0x10286, tf_esp = 0xc12670e0,
       tf_ss = 0xc11da620}) at ../../i386/i386/trap.c:478
 #30 0xc0165fb0 in dscheck (bp=0xc11da620, ssp=0xc160a300) at
 ../../kern/subr_diskslice.c:198
 #31 0xc0165c29 in diskioctl (dev=0xc11da620, cmd=0xc1351680,
 data=0xc1283b98 "home", fflag=0xc1900d00, p=0xc64f88c0)
     at ../../kern/subr_disk.c:210
 #32 0xc12987a3 in launch_requests (rq=0xc1900d00, reviveok=0x0)
     at /bsd/misc/src/sys/modules/vinum/../../dev/vinum/vinumrequest.c:431
 #33 0xc129849e in vinumstart (bp=0xc64f88c0, reviveok=0x0)
     at /bsd/misc/src/sys/modules/vinum/../../dev/vinum/vinumrequest.c:291
 #34 0xc1298306 in vinumstrategy (bp=0xc64f88c0) at
 /bsd/misc/src/sys/modules/vinum/../../dev/vinum/vinumrequest.c:164
 #35 0xc0191230 in spec_freeblks (ap=0xce2dbca0) at
 ../../miscfs/specfs/spec_vnops.c:499
 #36 0xc0190c6d in spec_open (ap=0xce2dbca0) at
 ../../miscfs/specfs/spec_vnops.c:147
 #37 0xc0211e15 in default_pager_alloc (handle=0xce2dbca0,
 size=0x1c64f88c0, prot=0x0, offset=0xce2e5c80c02959a0)
     at ../../vm/default_pager.c:82
 #38 0xc0211775 in ufs_print (ap=0xce2dbce4) at
 ../../ufs/ufs/ufs_vnops.c:1804
 #39 0xc0211de5 in ufs_vnoperatespec (ap=0xce2dbce4) at
 ../../ufs/ufs/ufs_vnops.c:2390
 #40 0xc017e50a in bwrite (bp=0xc64f88c0) at ../../kern/vfs_bio.c:264
 #41 0xc01839da in vop_sharedlock (ap=0xce2dbd20) at
 ../../kern/vfs_default.c:354
 #42 0xc0183835 in vop_panic (ap=0xce2dbd20) at
 ../../kern/vfs_default.c:146
 #43 0xc0211de5 in ufs_vnoperatespec (ap=0xce2dbd20) at
 ../../ufs/ufs/ufs_vnops.c:2390
 #44 0xc017e84e in bowrite (bp=0xc64f88c0) at vnode_if.h:1191
 #45 0xc01830f7 in cluster_wbuild () at ../../kern/vfs_cluster.c:884
 #46 0xc0182c0e in cluster_write (bp=0xc654d548, filesize=0x700000,
 seqcount=0x7f) at ../../kern/vfs_cluster.c:669
 #47 0xc020ad2a in ffs_write (ap=0xce2dbe68) at
 ../../ufs/ufs/ufs_readwrite.c:517
 #48 0xc018d1cc in vn_write (fp=0xc176d9c0, uio=0xce2dbed8,
 cred=0xc1406980, flags=0x0, p=0xce2a8a80)
     at ../../kern/vfs_vnops.c:388
 #49 0xc016a751 in dofilewrite (p=0xce2a8a80, fp=0xc176d9c0, fd=0x3,
 buf=0x80a0000, nbyte=0x2800,
     offset=0xffffffffffffffff, flags=0x0) at ../../kern/sys_generic.c:409
 #50 0xc016a60a in write () at ../../kern/sys_generic.c:332
 ---Type <return> to continue, or q <return> to quit---
 #51 0xc02517d5 in syscall2 (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds =
 0x2f, tf_edi = 0x80a0000, tf_esi = 0x2800,
       tf_ebp = 0xbfbff9fc, tf_isp = 0xce2dbfd4, tf_ebx = 0x80a0000, tf_edx
 = 0x3, tf_ecx = 0x0, tf_eax = 0x4,
       tf_trapno = 0x7, tf_err = 0x2, tf_eip = 0x8080f9c, tf_cs = 0x1f,
 tf_eflags = 0x293, tf_esp = 0xbfbff9d0,
       tf_ss = 0x2f}) at ../../i386/i386/trap.c:1161
 #52 0xc02459b5 in fork_trampoline ()
 #53 0x80524aa in ?? ()
 #54 0x8054541 in ?? ()
 #55 0x805a7fe in ?? ()
 #56 0x8048135 in ?? ()
 
 
 >
 > Greg
 > --
 > Finger grog@lemis.com for PGP public key
 > See complete headers for address and phone numbers
 >
 
 -- 
 Physikalisches Institut der Universitaet Bonn
 Nussallee 12
 D-53115 Bonn
 GERMANY
 

From: Jan Conrad <conrad@th.physik.uni-bonn.de>
To: Greg Lehey <grog@lemis.com>
Cc: David Malone <dwmalone@maths.tcd.ie>, <freebsd-bugs@FreeBSD.ORG>,
	<freebsd-gnats-submit@FreeBSD.ORG>
Subject: Re: misc/27498: vinum crashed after 'vinum dumpconfig' 
Date: Tue, 22 May 2001 10:49:09 +0200 (CEST)

 On Tue, 22 May 2001, David Malone wrote:
 
 > > Both of you: are you using devfs?
 >
 > Nope - the machine I crashed was running a relatively recent 4.X.
 > I still haven't been close enough to it to see exactly what the
 > panic was.
 >
 I am not using it either
 
 -Jan
 
State-Changed-From-To: open->feedback 
State-Changed-By: grog 
State-Changed-When: Sat Jun 14 18:37:23 PDT 2003 
State-Changed-Why:  
Seeking feedback from the submitter. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=27498 

From: jan_conrad@WestLB-Systems.de
To: freebsd-gnats-submit@FreeBSD.org, conrad@th.physik.uni-bonn.de
Cc:  
Subject: Re: misc/27498: vinum crashed after 'vinum dumpconfig'
Date: Mon, 16 Jun 2003 09:02:59 +0100

 Hi Greg,
 
 I've never heard of the problem again (from those guys who're now running
 the boxes)
 
 Regards
      Jan
 
 WestLB-Systems
 Department 771-80210
 Friedrichstr. 56
 D - 40217 D=FCsseldorf
 Tel.: +49 211 826  8971
 Mobile: +49 163 826 8971
 Fax: +49 211 826  6198
 EMail: jan_conrad@WestLB-Systems.de
 
State-Changed-From-To: feedback->closed 
State-Changed-By: grog 
State-Changed-When: Tue Jun 17 22:20:42 PDT 2003 
State-Changed-Why:  
PR closed at submitter's request. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=27498 
>Unformatted:

Greg Lehey, 15 June 2003

I have never been able to reproduce this problem.  I've made a number
of changes in Vinum configuration since the PR, and it's possible that
one of the changes has fixed this problem.  Can you still reproduce
it?

Greg Lehey, 18 June 2003

PR closed at submitter's request.
