[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
panic: vm_object_paging_begin
Hi guys
I've been running OpenBSD 2.1 and 2.2 for about 10 months
now and I'm very happy with it. It's probably the best one can
find to host fw/proxy services and sleep peacefully at nights...
Yesterday however I got a panic on one of my OpenBSD boxes:
# gdb -k bsd.0 -c bsd.0.core
GDB is free software and you are welcome to 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.
GDB 4.11 (i386-openbsd), Copyright 1993 Free Software Foundation, Inc...
(no debugging symbols found)...
panic: vm_object_paging_begin
#0 0x2000000 in ?? ()
(kgdb)
The autopsy shows:
# pstat -T -N bsd.0 -M bsd.0.core
320/1772 files
775 vnodes
38M/127M swap space
# pstat -s -N bsd.0 -M bsd.0.core
Device 1K-blocks Used Avail Capacity Type
/dev/wd0b 131040 39448 91592 30% Interleaved
I guess these are normal figures. A ps auwx on the core shows
(first 3 lines):
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 2 7.9 0.0 0 0 ?? RL 17Feb98 0:31.84 (pagedaemon)
mail 3465 3.1 0.0 536 0 ?? S 5:10PM 0:00.05 sendmail: RAA03465
protector.intrasoft.gr [195.170.17.132]: DATA (
root 1 0.0 0.0 300 0 ?? Ss 17Feb98 0:01.18 /sbin/init
...and this is a vmstat -m output:
-----BEGIN-----
Memory statistics by bucket size
Size In Use Free Requests HighWater Couldfree
16 595 429 647361 1280 0
32 1420 1268 582361 640 35
64 3469 1907 5869125 320 583
128 2396 2372 37167627 160 45519
256 1359 449 5077986 80 39
512 58 54 715 40 65
1024 134 26 10692440 20 6731813
2048 23 1 26 10 0
4096 3 0 7 5 0
8192 1 0 1 5 0
16384 8 0 8 5 0
Memory usage type by bucket size
Size Type(s)
16 devbuf, pcb, routetbl, namecache, VM objhash, VM pgdata, proc, exec,
IP queue ent, temp
32 devbuf, pcb, routetbl, pgrp, session, vnodes, VM pager, VM pgdata,
subproc, LFS segment, ether_multi
64 devbuf, pcb, routetbl, ifaddr, namecache, VM mapent, VM pgdata, file,
lockf, LFS segment, in_multi
128 mbuf, devbuf, pcb, routetbl, fragtbl, zombie, ifaddr, soopts, cred,
vnodes, VM object, VM pgdata, proc, ttys, exec
256 devbuf, socket, pcb, routetbl, ioctlops, vnodes, VM map, VM pgdata,
file desc, proc, subproc, FFS node, NFS srvsock, NFS daemon, ttys,
pfil, temp
512 devbuf, pcb, ioctlops, mount, UFS mount, VM pgdata, file desc, proc
1024 devbuf, namei, namecache, VM pgdata, file desc, NQNFS Lease,
MSDOSFS mount, ttys, exec
2048 mbuf, devbuf, NFS node, namecache, UFS quota, UFS mount, file desc,
ISOFS mount
4096 devbuf, UFS mount
8192 devbuf
16384 devbuf
Memory statistics by type Type Kern
Type InUse MemUse HighUse Limit Requests Limit Limit Size(s)
mbuf 306 41K 263K 3687K 33825090 0 0 128,2048
devbuf 101 156K 156K 3687K 151 0 0
16,32,64,128,256,512,1024,2048,4096,8192,16384
socket 127 32K 94K 3687K 373355 0 0 256
pcb 239 44K 137K 3687K 534377 0 0 16,32,64,128,256,512
routetbl 213 16K 17K 3687K 9701 0 0 16,32,64,128,256
fragtbl 0 0K 1K 3687K 8 0 0 128
zombie 2 1K 2K 3687K 122100 0 0 128
ifaddr 13 2K 2K 3687K 13 0 0 64,128
soopts 0 0K 1K 3687K 64607 0 0 128
namei 0 0K 24K 3687K 10680163 0 0 1024
ioctlops 0 0K 1K 3687K 554 0 0 256,512
cred 28 4K 11K 3687K 24561 0 0 128
pgrp 39 2K 3K 3687K 21588 0 0 32
session 33 2K 3K 3687K 19817 0 0 32
mount 8 4K 5K 3687K 10 0 0 512
NFS node 1 2K 2K 3687K 1 0 0 2048
vnodes 1164 114K 125K 3687K 49852 0 0 32,128,256
namecache 783 52K 52K 3687K 783 0 0 16,64,1024,2048
UFS quota 1 2K 2K 3687K 1 0 0 2048
UFS mount 25 40K 40K 3687K 25 0 0 512,2048,4096
VM map 65 17K 31K 3687K 483375 0 0 256
VM mapent 2245 141K 228K 3687K 4096014 0 0 64
VM object 940 118K 207K 3687K 2522862 0 0 128
VM objhash 164 3K 3K 3687K 265 0 0 16
VM pager 487 16K 31K 3687K 171059 0 0 32
VM pgdata 810 42K 101K 3687K 341853 0 0 16,32,64,128,256,512,1024
file 320 20K 47K 3687K 1611623 0 0 64
file desc 62 18K 31K 3687K 122196 0 0 256,512,1024,2048
lockf 21 2K 5K 3687K 135477 0 0 64
proc 69 17K 32K 3687K 123886 0 0 16,128,256,512
subproc 65 3K 5K 3687K 122272 0 0 32,256
LFS segment 0 0K 2K 3687K 45471 0 0 32,64
FFS node 775 194K 194K 3687K 3681760 0 0 256
NQNFS Lease 1 1K 1K 3687K 1 0 0 1024
NFS srvsock 2 1K 1K 3687K 2 0 0 256
NFS daemon 1 1K 1K 3687K 1 0 0 256
in_multi 3 1K 1K 3687K 3 0 0 64
ether_multi 2 1K 1K 3687K 2 0 0 32
ISOFS mount 1 2K 2K 3687K 1 0 0 2048
MSDOSFS mount 1 1K 1K 3687K 1 0 0 1024
ttys 252 147K 147K 3687K 252 0 0 128,256,1024
exec 0 0K 3K 3687K 238022 0 0 16,128,1024
IP queue ent 10 1K 1K 3687K 402578 0 0 16
pfil 65 17K 17K 3687K 538 0 0 256
temp 22 6K 12K 3687K 211386 0 0 16,256
Memory Totals: In Use Free Requests
1267K 630K 60037657
-----END-----
The crashed machine runs squid and carries a lot of sendmail
traffic. Yet, so do two other boxes with zero problems, running
for about 3 months now (uptime 82 days). It's the first crash I've
had with OpenBSD ever. Is it a one-in-a-million case?
The host is running OpenBSD 2.2. I haven't tweaked any options
regarding VM etc (I haven't even touched maxusers). I took a peek
in vm/vm_object.h where the panic is defined:
#ifndef DIAGNOSTIC
#define vm_object_paging_begin(object) \
do { \
(object)->paging_in_progress++; \
} while (0)
#else
#define vm_object_paging_begin(object) \
do { \
if ((object)->paging_in_progress == 0xdead) \
panic("vm_object_paging_begin"); \
(object)->paging_in_progress++; \
} while (0)
#endif
The kernel was compiled with DIAGNOSTICS on, so I guess it crashed on
an internal consistency check.
(oh, yes, I'd like to thank all you guys for building this
great OS! I believe it is really the best for securing networks
and building custom firewalls - it won't let you down even if you
mess with it).
Thanks!
----------------------------------------------------------------
Valakas Antonis INTRASOFT S.A.
valakas@intrasoft.gr [ I speak for myself ]