Re: CURRENT: Crash in multiuser mode while shutdown
Am Sun, 19 Feb 2023 06:19:04 -0800 Rick Macklem schrieb: > I committed a patch that would cause crashes if > the system was using jails on Feb. 11, but it was > fixed the next day. It bogusly had a prison_cleanup() > method in it. > > But if you kernel wasn't from main on about Feb. 11 > or you aren't running jails, I don't think this is it. Sources are most recent. > > It is too bad you don't have a backtrace? I need the box today, the other one is a poudriere host and can't be interrupted on short notice, I will enable debugging as I finish my work. The I hope I can provide you with a backtrace. cpu-data has been updated recently, I use this on these two IvyBridge methusalem riggs, I may disable this first and see what happens ... Regards oh > > rick > > On Sun, Feb 19, 2023 at 1:38 AM FreeBSD User wrote: > > > > Hello, > > > > most recent CURRENT crashes on shutdown from multiuser mode (singleuser > > mode, used after > > repairing failed FFS filesystems, is all right). The crashes go on since > > roughly a 1/2 week > > from now. The boxes involved are all cumtomized kernels (in most cases hard > > linked modules > > into kernel). Is there a known issue? > > > > Otherwise I have to reconfigure all systems for debugging an d will report > > aftwards more. > > > > > > Regards and thanks in advance > > Oliver > > -- > > O. Hartmann > > -- O. Hartmann
Re: -CURRENT crash under high exec() loads.. (vm_map_insert?)
:If you notice, both times it crashed on vm_map_insert. Try bumping up PMAP_SHPGPERPROC. From LINT: # # Set the number of PV entries per process. Increasing this can # stop panics related to heavy use of shared memory. However, that can # (combined with large amounts of physical memory) cause panics at # boot time due the kernel running out of VM space. # # If you're tweaking this, you might also want to increase the sysctls # "vm.v_free_min", "vm.v_free_reserved", and "vm.v_free_target". # # The value below is the one more than the default. # options PMAP_SHPGPERPROC=201 Try bumping it up to 1000 and see if that solves your crashes. If that doesn't work, and there's any chance of getting a kernel dump, try getting a kernel dump. Make sure you use a debug (compiled -g) kernel. While I can't say I truly see the correlation, you definitely know more about how it works then me. I've cvsupp'd and upped it to 1000. One question I have, is what exactly -are- pv's? The machine itself isn't under too much load during the testing, and definitely does not used a lot of shared memory. During one of the tests yesterday (c89) it was doing ~8000 execs per minute, with a load of 0.23. I've also got plenty of RAM left over. Here is what it currently looks like: last pid: 7121; load averages: 0.75, 0.31, 0.15 up 0+00:16:15 09:21:55 59 processes: 3 running, 56 sleeping CPU states: 36.0% user, 0.0% nice, 63.2% system, 0.8% interrupt, 0.0% idle Mem: 57M Active, 8412K Inact, 16M Wired, 2292K Cache, 9628K Buf, 8280K Free Swap: 786M Total, 22M Used, 764M Free, 2% Inuse This is basically X, Netscape, and 5800 exec()'s a minute. I've got debugging in my kernel, and I'll send you full results if and when it crashes again. -- == thomas r. stromberg smtp:[EMAIL PROTECTED] assistant is manager / systems guru http://thomas.stromberg.org research triangle commerce, inc.finger:[EMAIL PROTECTED] 'om mani pedme hung'pots://1.919.380.9771:3210 [eof]= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT crash under high exec() loads.. (vm_map_insert?)
: that doesn't work, and there's any chance of getting a kernel dump, : try getting a kernel dump. Make sure you use a debug (compiled -g) : kernel. : : :While I can't say I truly see the correlation, you definitely know more :about how it works then me. I've cvsupp'd and upped it to 1000. One :question I have, is what exactly -are- pv's? PV's are a mistake, but nobody has figured out a better way to do it. PV's are essentially FreeBSD's way of managing page tables. They associated a physical page with an entry in a process's page table and allow the VM system to track which physical pages are mapped (and where), and which are not. This in turn reduces the overhead of many of the algorithms in the VM system and allows the system to scale. However, it costs memory to do this and it has an achilles heel - shared address spaces can exhaust the pool without exhausting physical memory. :The machine itself isn't under too much load during the testing, and :definitely does not used a lot of shared memory. During one of the tests :yesterday (c89) it was doing ~8000 execs per minute, with a load of :0.23. I've also got plenty of RAM left over. Here is what it currently :looks like: Yah. I don't know if that's it or not, but whenever systems crash that deep into the VM system the first thing we try is to up the number of PV's. :Free :Swap: 786M Total, 22M Used, 764M Free, 2% Inuse : :This is basically X, Netscape, and 5800 exec()'s a minute. : :I've got debugging in my kernel, and I'll send you full results if and :when it crashes again. :thomas r. stromberg smtp:[EMAIL PROTECTED] Both X and netscape have large run sizes. Any fork/exec from either of those programs will create a temporary spike in resource use. I could be totally wrong but it's definitely suspect and worth trying. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT crash under high exec() loads.. (vm_map_insert?)
:the timeout to kill it off because of the interactive mode. Otherwise :there was ~960,000 accumulated exec()'s altogether in a 5 hour period. : :As you can see, cron is the process that crashed it. Two weeks ago it :was an eggdrop. I've not had any crashes in -CURRENT while this program :was not running however. : :If you notice, both times it crashed on vm_map_insert. Try bumping up PMAP_SHPGPERPROC. From LINT: # # Set the number of PV entries per process. Increasing this can # stop panics related to heavy use of shared memory. However, that can # (combined with large amounts of physical memory) cause panics at # boot time due the kernel running out of VM space. # # If you're tweaking this, you might also want to increase the sysctls # "vm.v_free_min", "vm.v_free_reserved", and "vm.v_free_target". # # The value below is the one more than the default. # options PMAP_SHPGPERPROC=201 Try bumping it up to 1000 and see if that solves your crashes. If that doesn't work, and there's any chance of getting a kernel dump, try getting a kernel dump. Make sure you use a debug (compiled -g) kernel. -Matt Matthew Dillon [EMAIL PROTECTED] :Fatal trap 12: page fault while in kernel mode :fault virtual address = 0x8 :fault code = supervisor write, page not present :instruction pointer = 0x8:0xc01d7a67 :stack pointer = 0x10:0xccd67df0 :frame pointer = 0x10:0xccd67e0c :code segment= base 0x0, limit 0xf, type 0x1b := DPL 0, pres 1, def32 1, gran 1 :processor eflags= interrupt enabled, resume, IOPL = 0 :current process = 128 (cron) :interrupt mask = none :trap number = 12 :panic: page fault : :syncing disks... 32 9 :done : :dumping to dev #wd/0x20001, offset 1413889 :dump 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 0xc0131e80 in boot () :#1 0xc013221d in panic () :#2 0xc0215102 in trap_fatal () :#3 0xc0214db5 in trap_pfault () :#4 0xc0214987 in trap () :#5 0xc01d7a67 in vm_map_insert () === :#6 0xc01d7c88 in vm_map_find () :#7 0xc01d6e93 in kmem_alloc_pageable () :#8 0xc0211a3e in pmap_pinit () :#9 0xc01d7650 in vmspace_alloc () :#10 0xc01d950c in vmspace_fork () :#11 0xc01d6a28 in vm_fork () :#12 0xc012c96f in fork1 () :#13 0xc012c1f6 in fork () :#14 0xc021533a in syscall () :#15 0xc0209d36 in Xint0x80_syscall () :#16 0x804aeee in ?? () :#17 0x8049c4d in ?? () :#18 0x8049a15 in ?? () :#19 0x80497d9 in ?? () : :thomas r. stromberg smtp:[EMAIL PROTECTED] :assistant is manager / systems guru http://thomas.stromberg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current crash
On Monday, 18 October 1999 at 2:09:49 +0200, Michael Reifenberger wrote: On Mon, 18 Oct 1999, Greg Lehey wrote: Date: Mon, 18 Oct 1999 12:50:04 +1300 From: Greg Lehey [EMAIL PROTECTED] To: Michael Reifenberger [EMAIL PROTECTED] Cc: Matthew Jacob [EMAIL PROTECTED], FreeBSD-Current [EMAIL PROTECTED] Subject: Re: -current crash ... OK, this is what I was afraid of. I'm committing some fixes. Thanks. I'm leaving for the USA in a few hours. If you could test that before, it would help; otherwise it might be a while before I can look at it again. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current crash
On Monday, 18 October 1999 at 1:35:16 +0200, Michael Reifenberger wrote:
On Mon, 18 Oct 1999, Greg Lehey wrote:
Date: Mon, 18 Oct 1999 12:16:19 +1300
From: Greg Lehey [EMAIL PROTECTED]
To: Michael Reifenberger [EMAIL PROTECTED],
Matthew Jacob [EMAIL PROTECTED]
Cc: FreeBSD-Current [EMAIL PROTECTED]
Subject: Re: -current crash
...
Have you rebuilt the kld?
kernel,modules,world are in sync.
The same configuration worked for several weeks without problems.
BTW: where does the 0xdeadc0de (0xDeadCode ?) below come from?
Info to frame5:
(kgdb) rq
Request:
{
bp = 0xdeadc0de,
flags = 0xc0261140,
volplex = {
volno = 0xdeadc0de,
plexno = 0xdeadc0de
},
error = 0xc121c800,
sdno = 0xdeadc0de,
isplex = 0xc0de,
active = 0xdead,
rqg = 0xdeadc0de,
lrqg = 0xdeadc0de,
next = 0xdeadc0de
}
Cannot access memory at address 0xdeadc136.
OK, this is what I was afraid of. I'm committing some fixes.
Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -current crash
On Monday, 18 October 1999 at 0:43:21 +0200, Michael Reifenberger wrote: On Sun, 17 Oct 1999, Matthew Jacob wrote: Date: Sun, 17 Oct 1999 15:08:10 -0700 (PDT) From: Matthew Jacob [EMAIL PROTECTED] To: Michael Reifenberger [EMAIL PROTECTED] Cc: FreeBSD-Current [EMAIL PROTECTED] Subject: Re: -current crash Doesn't tell *me* a lot maybe a broken driver that's a KLD? It looks like something from spec_strategy is being called that's not in the /kernel space- could be a KLD- are your KLDs up to date for the new kernel? Like, is this vinum perhaps? Seems so. After using the .gdbinit* stuff from modules/vinum I get the missing pices: ... #5 0xc101e91b in launch_requests (rq=0xc17d3f00, reviveok=0x0) at /usr/src/sys/modules/vinum/../../dev/vinum/vinumrequest.c:387 #6 0xc101e752 in vinumstart (bp=0xc62f8f30, reviveok=0x0) at /usr/src/sys/modules/vinum/../../dev/vinum/vinumrequest.c:299 #7 0xc101e54e in vinumstrategy (bp=0xc62f8f30) at /usr/src/sys/modules/vinum/../../dev/vinum/vinnumrequest.c:164 ... Have you rebuilt the kld? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current crash
On Sunday, 17 October 1999 at 22:42:51 +0200, Michael Reifenberger wrote: Hi, I got the following crash since a couple of time since upgrading one machine to -current as of today. It seems to occurs during somewhat heavier diskaccess. Sorry no detailed backtrace for now because I deleted my kernel.debug since the last crash and dumping 256MB takes a long time... Does the crash trigger anything. --- #0 0xc0152368 in boot () #0 0xc0152368 in boot () #1 0xc0152741 in panic () #2 0xc0211b40 in trap_fatal () #3 0xc02117b1 in trap_pfault () #4 0xc0211313 in trap () #5 0xc101891b in ?? () #6 0xc1018752 in ?? () #7 0xc101854e in ?? () #8 0xc0186a66 in spec_strategy () #9 0xc018601d in spec_vnoperate () #10 0xc01bb351 in ufs_vnoperatespec () #11 0xc0173bf7 in bread () #12 0xc01ac05b in ffs_update () #13 0xc01b60d6 in ufs_inactive () #14 0xc01bb321 in ufs_vnoperate () #15 0xc017bf81 in vrele () #16 0xc018257b in vn_close () #17 0xc0182de8 in vn_closefile () #18 0xc014a81d in fdrop () #19 0xc014a7d3 in closef () #20 0xc0149e0c in close () #21 0xc0211df1 in syscall () #22 0x200d44f1 in ?? () snip (kgdb) quit Well, without debugging symbols it's difficult to guess what's going on here. Frames 5 to 7 are interesting. Either you've run into the woods, or you're using a kld. Is this with Vinum, perhaps? If so, you should read vinum(4) or http://www.lemis.com/vinum/how-to-debug.html. Otherwise you should at least build a debug kernel; the references could help there too. On Sunday, 17 October 1999 at 13:50:27 -0700, Matthew Jacob wrote: Well, a DDB traceback would help. Failing that, at least what does 0xc101891b correspond to otherwise, it's all ENOGUESS A ddb traceback will give you a little more information (some parameters), but I don't think that it's much better. -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current crash
Well, a DDB traceback would help. Failing that, at least what does 0xc101891b correspond to otherwise, it's all ENOGUESS On Sun, 17 Oct 1999, Michael Reifenberger wrote: Hi, I got the following crash since a couple of time since upgrading one machine to -current as of today. It seems to occurs during somewhat heavier diskaccess. Sorry no detailed backtrace for now because I deleted my kernel.debug since the last crash and dumping 256MB takes a long time... Does the crash trigger anything. SMP 2 cpus IdlePTD 3194880 initial pcb at 282c40 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode mp_lock = 0002; cpuid = 0; lapic.id = 0100 fault virtual address = 0xdeadc0e6 fault code = supervisor read, page not present instruction pointer = 0x8:0xc101891b stack pointer = 0x10:0xce004d3c frame pointer = 0x10:0xce004d4c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 6296 (bash) interrupt mask = none - SMP: XXX trap number = 12 panic: page fault mp_lock = 0002; cpuid = 0; lapic.id = 0100 boot() called on cpu#0 Bye! Michael Reifenberger Plaut Software GmbH, R/3 Basis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current crash
On Sun, 17 Oct 1999, Matthew Jacob wrote:
...
Well, a DDB traceback would help. Failing that, at least what does
0xc101891b correspond to otherwise, it's all ENOGUESS
Next try, next crash. No problem. Easy crashing :-)
I tried to find the address 0xc101891b using nm(1) but can't seem to find it.
Whats the preffered method for finding?
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
SMP 2 cpus
IdlePTD 3194880
initial pcb at 282c20
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 0102; cpuid = 1; lapic.id =
fault virtual address = 0xdeadc0e6
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc101e91b
stack pointer = 0x10:0xce042cbc
frame pointer = 0x10:0xce042ccc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 16328 (dbv)
interrupt mask = none - SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0102; cpuid = 1; lapic.id =
boot() called on cpu#1
syncing disks... 3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 done
dumping to dev #da/0x20001, offset 540696
dump 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 boot (howto=256) at ../../kern/kern_shutdown.c:280
280 dumppcb.pcb_cr3 = rcr3();
#0 boot (howto=256) at ../../kern/kern_shutdown.c:280
#1 0xc015275d in panic (fmt=0xc02520cf "page fault") at ../../kern/kern_shutdown.c:530
#2 0xc0211b30 in trap_fatal (frame=0xce042c7c, eva=3735929062) at
../../i386/i386/trap.c:907
#3 0xc02117a1 in trap_pfault (frame=0xce042c7c, usermode=0, eva=3735929062)
at ../../i386/i386/trap.c:800
#4 0xc0211303 in trap (frame={tf_fs = -1057095656, tf_es = -1052377072, tf_ds =
-1056112624,
tf_edi = -559038242, tf_esi = -1052325860, tf_ebp = -838587188, tf_isp =
-838587224,
tf_ebx = -1056083712, tf_edx = -1070995904, tf_ecx = 16777217, tf_eax = -16162,
tf_trapno = 12, tf_err = 0, tf_eip = -1056839397, tf_cs = 8, tf_eflags = 66182,
tf_esp = -1055894172, tf_ss = -969961680}) at ../../i386/i386/trap.c:426
#5 0xc101e91b in ?? ()
#6 0xc101e752 in ?? ()
#7 0xc101e54e in ?? ()
#8 0xc0186a82 in spec_strategy (ap=0xce042d4c) at ../../miscfs/specfs/spec_vnops.c:686
#9 0xc0186039 in spec_vnoperate (ap=0xce042d4c) at
../../miscfs/specfs/spec_vnops.c:133
#10 0xc01bb371 in ufs_vnoperatespec (ap=0xce042d4c) at ../../ufs/ufs/ufs_vnops.c:2313
#11 0xc01bad70 in ufs_strategy (ap=0xce042dd4) at vnode_if.h:940
#12 0xc01bb341 in ufs_vnoperate (ap=0xce042dd4) at ../../ufs/ufs/ufs_vnops.c:2295
#13 0xc0177e06 in cluster_read (vp=0xce16f380, filesize=1258299392, lblkno=137260,
size=8192,
cred=0x0, totread=8192, seqcount=127, bpp=0xce042e70) at vnode_if.h:940
#14 0xc01b4517 in ffs_read (ap=0xce042e98) at ../../ufs/ufs/ufs_readwrite.c:249
#15 0xc0182800 in vn_read (fp=0xc121cac0, uio=0xce042ee8, cred=0xc1224c80, flags=0,
p=0xcdfc8500) at vnode_if.h:330
#16 0xc015fdf4 in dofileread (p=0xcdfc8500, fp=0xc121cac0, fd=4, buf=0x28418cd0,
nbyte=8192,
offset=-1, flags=0) at ../../sys/file.h:135
#17 0xc015fcfb in read (p=0xcdfc8500, uap=0xce042f80) at ../../kern/sys_generic.c:110
#18 0xc0211de1 in syscall (frame={tf_fs = 65583, tf_es = 47, tf_ds = -1078001617,
tf_edi = 137217, tf_esi = 0, tf_ebp = -1077947392, tf_isp = -838586412, tf_ebx =
4,
tf_edx = 8192, tf_ecx = 675384528, tf_eax = 3, tf_trapno = 7, tf_err = 2,
tf_eip = 674927924, tf_cs = 31, tf_eflags = 658, tf_esp = -1077947420, tf_ss =
47})
at ../../i386/i386/trap.c:1056
#19 0xc01fe9b1 in Xint0x80_syscall ()
(kgdb) quit
Bye!
Re: -current crash
On Sun, Oct 17, 1999 at 10:42:51PM +0200, Michael Reifenberger wrote: [...] #3 0xc02117b1 in trap_pfault () #4 0xc0211313 in trap () #5 0xc101891b in ?? () #6 0xc1018752 in ?? () #7 0xc101854e in ?? () #8 0xc0186a66 in spec_strategy () #9 0xc018601d in spec_vnoperate () [...] What kind of modules were you running? Are these in sync with the kernel? -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current crash
Doesn't tell *me* a lot maybe a broken driver that's a KLD? It looks
like something from spec_strategy is being called that's not in the
/kernel space- could be a KLD- are your KLDs up to date for the new
kernel? Like, is this vinum perhaps?
On Sun, 17 Oct 1999, Matthew Jacob wrote:
...
Well, a DDB traceback would help. Failing that, at least what does
0xc101891b correspond to otherwise, it's all ENOGUESS
Next try, next crash. No problem. Easy crashing :-)
I tried to find the address 0xc101891b using nm(1) but can't seem to find it.
Whats the preffered method for finding?
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
SMP 2 cpus
IdlePTD 3194880
initial pcb at 282c20
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 0102; cpuid = 1; lapic.id =
fault virtual address = 0xdeadc0e6
fault code= supervisor read, page not present
instruction pointer = 0x8:0xc101e91b
stack pointer = 0x10:0xce042cbc
frame pointer = 0x10:0xce042ccc
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 16328 (dbv)
interrupt mask= none - SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0102; cpuid = 1; lapic.id =
boot() called on cpu#1
syncing disks... 3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 done
dumping to dev #da/0x20001, offset 540696
dump 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 boot (howto=256) at ../../kern/kern_shutdown.c:280
280 dumppcb.pcb_cr3 = rcr3();
#0 boot (howto=256) at ../../kern/kern_shutdown.c:280
#1 0xc015275d in panic (fmt=0xc02520cf "page fault") at
../../kern/kern_shutdown.c:530
#2 0xc0211b30 in trap_fatal (frame=0xce042c7c, eva=3735929062) at
../../i386/i386/trap.c:907
#3 0xc02117a1 in trap_pfault (frame=0xce042c7c, usermode=0, eva=3735929062)
at ../../i386/i386/trap.c:800
#4 0xc0211303 in trap (frame={tf_fs = -1057095656, tf_es = -1052377072, tf_ds =
-1056112624,
tf_edi = -559038242, tf_esi = -1052325860, tf_ebp = -838587188, tf_isp =
-838587224,
tf_ebx = -1056083712, tf_edx = -1070995904, tf_ecx = 16777217, tf_eax =
-16162,
tf_trapno = 12, tf_err = 0, tf_eip = -1056839397, tf_cs = 8, tf_eflags =
66182,
tf_esp = -1055894172, tf_ss = -969961680}) at ../../i386/i386/trap.c:426
#5 0xc101e91b in ?? ()
#6 0xc101e752 in ?? ()
#7 0xc101e54e in ?? ()
#8 0xc0186a82 in spec_strategy (ap=0xce042d4c) at
../../miscfs/specfs/spec_vnops.c:686
#9 0xc0186039 in spec_vnoperate (ap=0xce042d4c) at
../../miscfs/specfs/spec_vnops.c:133
#10 0xc01bb371 in ufs_vnoperatespec (ap=0xce042d4c) at ../../ufs/ufs/ufs_vnops.c:2313
#11 0xc01bad70 in ufs_strategy (ap=0xce042dd4) at vnode_if.h:940
#12 0xc01bb341 in ufs_vnoperate (ap=0xce042dd4) at ../../ufs/ufs/ufs_vnops.c:2295
#13 0xc0177e06 in cluster_read (vp=0xce16f380, filesize=1258299392, lblkno=137260,
size=8192,
cred=0x0, totread=8192, seqcount=127, bpp=0xce042e70) at vnode_if.h:940
#14 0xc01b4517 in ffs_read (ap=0xce042e98) at ../../ufs/ufs/ufs_readwrite.c:249
#15 0xc0182800 in vn_read (fp=0xc121cac0, uio=0xce042ee8, cred=0xc1224c80, flags=0,
p=0xcdfc8500) at vnode_if.h:330
#16 0xc015fdf4 in dofileread (p=0xcdfc8500, fp=0xc121cac0, fd=4, buf=0x28418cd0,
nbyte=8192,
offset=-1, flags=0) at ../../sys/file.h:135
#17 0xc015fcfb in read (p=0xcdfc8500, uap=0xce042f80) at ../../kern/sys_generic.c:110
#18 0xc0211de1 in syscall (frame={tf_fs = 65583, tf_es = 47, tf_ds = -1078001617,
tf_edi = 137217, tf_esi = 0, tf_ebp =
Re: -current crash
On Mon, Oct 18, 1999 at 12:16:08AM +0200, Michael Reifenberger wrote: The combination of vinum raid5 and softupdates is known to trigger a bug which may look just as you described. I might help if you disable softupdates on the vinum volumes. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current crash
On Mon, 18 Oct 1999, Bernd Walter wrote: ... On Mon, Oct 18, 1999 at 12:16:08AM +0200, Michael Reifenberger wrote: The combination of vinum raid5 and softupdates is known to trigger a bug which may look just as you described. I might help if you disable softupdates on the vinum volumes. Right. But nix raid5. The volumes are raid0 or raid0+1 Bye! Michael Reifenberger Plaut Software GmbH, R/3 Basis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current crash
On Mon, 18 Oct 1999, Greg Lehey wrote: Date: Mon, 18 Oct 1999 12:50:04 +1300 From: Greg Lehey [EMAIL PROTECTED] To: Michael Reifenberger [EMAIL PROTECTED] Cc: Matthew Jacob [EMAIL PROTECTED], FreeBSD-Current [EMAIL PROTECTED] Subject: Re: -current crash ... OK, this is what I was afraid of. I'm committing some fixes. Thanks. Bye! Michael Reifenberger Plaut Software GmbH, R/3 Basis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current crash
the vinum module looks to have been the problem.. not ethat you had stack elements at 0xc101exxx vinum starts at 0c1011000, On Mon, 18 Oct 1999, Michael Reifenberger wrote: On Mon, 18 Oct 1999, Bernd Walter wrote: ... What kind of modules were you running? (nullum)(root)# kldstat Id Refs AddressSize Name 17 0xc010 1eb518 kernel 21 0xc02ec000 cdbc bktr.ko 31 0xc1011000 c3000vinum.ko 41 0xc000 6000 procfs.ko 51 0xc1118000 8000 if_xl.ko 61 0xc1121000 7000 miibus.ko 71 0xc131e000 4c000nfs.ko Are these in sync with the kernel? Yes. Configuration hasnt changed for weeks. boottext is attached. Softupdates is on on all FS. (Wasn't a problem so far) (nullum)(root)# mount /dev/da0s1a on / (ufs, local, soft-updates, writes: sync 5 async 274) /dev/da0s1d on /usr (ufs, NFS exported, local, soft-updates, writes: sync 172 async 5230) /dev/vinum/data on /mnt/data (ufs, NFS exported, local, soft-updates, writes: sync 2 async 0) /dev/vinum/oracle on /oracle (ufs, NFS exported, local, soft-updates, writes: sync 2 async 0) /dev/vinum/sapdaten on /oracle/NIL/sapdaten (ufs, local, soft-updates, writes: sync 2 async 0) /dev/vinum/sapmnt on /sapmnt (ufs, local, soft-updates, writes: sync 2 async 0) /dev/vinum/usr_sap on /usr/sap (ufs, NFS exported, local, soft-updates, writes: sync 2 async 0) procfs on /proc (procfs, local) Bye! Michael Reifenberger Plaut Software GmbH, R/3 Basis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current crash
On Mon, 18 Oct 1999, Greg Lehey wrote: Date: Mon, 18 Oct 1999 13:40:27 +1300 From: Greg Lehey [EMAIL PROTECTED] To: Michael Reifenberger [EMAIL PROTECTED] Subject: Re: -current crash Ok, seems to be fixed. A few stress tests which paniced reliable before do new work. Thanks for the fast response. And now have a nice and relaxed trip to the FreeBSDCon. BTW: could you remind Jordan to put the slides and docs online for those who are not there in SF. I've not seen anything else except the agenda on the webpage. Bye! Michael Reifenberger Plaut Software GmbH, R/3 Basis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current crash
On Sun, 17 Oct 1999, Julian Elischer wrote: ... the vinum module looks to have been the problem.. not ethat you had stack elements at 0xc101exxx vinum starts at 0c1011000, Yes. But you are too late :-) The fix is allready commited. Bye! Michael Reifenberger Plaut Software GmbH, R/3 Basis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
