Date: Thu, 4 Feb 1999 08:33:33 +0100 From: Bernd Walter <ticso@cicely.de> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Panic with 3.0-Stable SNAP 1999-02-02 Message-ID: <19990204083333.36857@cicely.de> In-Reply-To: <199902040017.QAA76195@apollo.backplane.com>; from Matthew Dillon on Wed, Feb 03, 1999 at 04:17:18PM -0800 References: <19990203192504.35970@cicely.de> <199902040017.QAA76195@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 03, 1999 at 04:17:18PM -0800, Matthew Dillon wrote:
Thank you for your quick reply.
> Hmmm. If you can, please go to frame 6 and print out '*z'. Also
> print out *kernel_map:
>
> frame 6
> print *z
> print *kernel_map
bash-2.02# gdb -k kernel.gdb vmcore.6
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.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...
IdlePTD 2740224
initial pcb at 225fa0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xf01ea7a7
stack pointer = 0x10:0xff5e6bcc
frame pointer = 0x10:0xff5e6bf0
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 = 208 (squid)
interrupt mask = bio
trap number = 12
panic: page fault
syncing disks... 194 194 194 194 194 194 194 194 194 194 194 194 194 194 194 194 194 194 194 194 giving up
dumping to dev 30401, offset 2023424
dump 512 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 26!
!
6 265 264 263 262 261 260 259 258 257 256 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 boot (howto=256) at ../../kern/kern_shutdown.c:285
285 dumppcb.pcb_cr3 = rcr3();
(kgdb) frame 6
#6 0xf015e6d8 in getnewvnode (tag=VT_UFS, mp=0xf2734e00, vops=0xf2667300,
vpp=0xff5e6c7c) at ../../vm/vm_zone.h:85
85 return _zget(z);
(kgdb) print *z
Cannot access memory at address 0x0.
(kgdb) print *kernel_map
$1 = {lock = {lk_interlock = {lock_data = -266052716}, lk_flags = 16777216,
lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 4,
lk_wmesg = 0xf0207601 "thrd_sleep", lk_timo = 0, lk_lockholder = -1},
header = {prev = 0xf024255c, next = 0xf0243524, start = 4026265600,
end = 4290772992, avail_ssize = 0, object = {vm_object = 0x0,
share_map = 0x0, sub_map = 0x0}, offset = 0x0000000000000000,
eflags = 0 '\000', protection = 0 '\000', max_protection = 0 '\000',
inheritance = 0 '\000', wired_count = 0}, nentries = 101,
size = 264495104, is_main_map = 1 '\001', system_map = 1 '\001',
hint = 0xf0243434, timestamp = 4475, first_free = 0xf024255c,
pmap = 0xf0253648}
>
> I'm not sure why it isn't listing the _zget() in a frame. It's hard
> to tell where the bzero is being called from.
>
> It appears to be trying to bzero() NULL, which means either
> kmem_malloc() or kmem_alloc() returned NULL. This in turn can only
> happen in a few specific instances, such as if you run out of KVM.
>
Yes I have got a dump showing me that allocation to kernel_map failed.
Thats why I CCed to you because I know your are very responsible about the VM system
Unlukily I don't have this special dump.
I forgot to mention that I've raised some values in sys/vm/vm_map.h beacuse of the first dumps:
/* XXX: number of kernel maps and entries to statically allocate */
#define MAX_KMAP 100
#define MAX_KMAPENT 1280
#define MAX_MAPENT 1280
original:
/* XXX: number of kernel maps and entries to statically allocate */
#define MAX_KMAP 10
#define MAX_KMAPENT 128
#define MAX_MAPENT 128
Interestingly I got one crash with top showing still over 300Meg on free pool - the
system was not up for long... - that was without sys/vm/vm_map.h modification.
> Please also do this:
>
> cd /var/crash
> vmstat -m -N kernel.gdb -M vmcore.6
bash-2.02# vmstat -m -N kernel.gdb -M vmcore.6
Memory statistics by bucket size
Size In Use Free Requests HighWater Couldfree
16 818 462 189520 1280 0
32 3615 97 21942 640 0
64 3046 26 188525 320 0
128 418 30 18495 160 0
256 18451 13 20293 80 0
512 230 2 4473 40 0
1K 40 56 15157 20 70
2K 31 5 206540 10 3
4K 20 0 102 5 0
8K 8 0 8 5 0
16K 4 0 4 5 0
32K 1 0 1 5 0
128K 2 0 2 5 0
256K 2 0 2 5 0
512K 1 0 1 5 0
Memory usage type by bucket size
Size Type(s)
16 kld, devbuf, temp, proc, sysctl, soname, pcb, vnodes, ether_multi,
routetbl
32 kld, sigio, devbuf, temp, pgrp, subproc, sysctl, pcb,
cluster_save buffer, vnodes, ifaddr, ether_multi, routetbl, in_multi
64 file, lockf, namecache, devbuf, temp, session, pcb,
cluster_save buffer, vnodes, ifaddr, routetbl, MFS node
128 kld, timecounter, file desc, zombie, namecache, devbuf, cred, ttys,
soname, vnodes, ifaddr, routetbl, ZONE
256 file desc, namecache, devbuf, temp, subproc, vnodes, routetbl,
NFS srvsock, NFS daemon, FFS node, MFS node
512 file desc, devbuf, temp, ioctlops, BIO buffer, mount, UFS mount
1K file desc, devbuf, temp, BIO buffer, NQNFS Lease
2K file desc, devbuf, temp, proc, ttys, pcb, BIO buffer, UFS mount
4K devbuf, temp, UFS mount
8K proc, UFS mount
16K devbuf, mbuf
32K devbuf
128K NFS hash, UFS ihash
256K namecache, temp
512K VM pgdata
Memory statistics by type Type Kern
Type InUse MemUse HighUse Limit Requests Limit Limit Size(s)
kld 4 1K 1K 40960K 5 0 0 16,32,128
timecounter 10 2K 2K 40960K 10 0 0 128
file desc 75 31K 35K 40960K 8803 0 0 128,256,512,1K,2K
file 395 25K 29K 40960K 169149 0 0 64
sigio 1 1K 1K 40960K 2 0 0 32
zombie 0 0K 1K 40960K 8695 0 0 128
lockf 1 1K 1K 40960K 93 0 0 64
namecache 2602 420K 420K 40960K 10334 0 0 64,128,256,256K
devbuf 782 302K 302K 40960K 1769 0 0 16,32,64,128,256,512,1K,2K,4K,16K,32K
temp 23 138K 168K 40960K 234285 0 0 16,32,64,256,512,1K,2K,4K,256K
pgrp 32 1K 2K 40960K 56 0 0 32
session 25 2K 2K 40960K 33 0 0 64
proc 7 19K 19K 40960K 8 0 0 16,2K,8K
subproc 135 7K 7K 40960K 17534 0 0 32,256
cred 31 4K 5K 40960K 66 0 0 128
sysctl 0 0K 1K 40960K 13 0 0 16,32
ioctlops 0 0K 1K 40960K 10 0 0 512
ttys 251 36K 36K 40960K 489 0 0 128,2K
soname 1 1K 1K 40960K 148515 0 0 16,128
pcb 573 14K 20K 40960K 40347 0 0 16,32,64,2K
BIO buffer 19 20K 78K 40960K 399 0 0 512,1K,2K
cluster_save buffer 0 0K 1K 40960K 211 0 0 32,64
mount 11 6K 6K 40960K 11 0 0 512
vnodes 43 6K 7K 40960K 996 0 0 16,32,64,128,256
ifaddr 11 1K 1K 40960K 11 0 0 32,64,128
ether_multi 7 1K 1K 40960K 7 0 0 16,32
routetbl 6359 894K 894K 40960K 6369 0 0 16,32,64,128,256
in_multi 2 1K 1K 40960K 2 0 0 32
NFS srvsock 2 1K 1K 40960K 2 0 0 256
NFS daemon 1 1K 1K 40960K 1 0 0 256
NQNFS Lease 1 1K 1K 40960K 1 0 0 1K
NFS hash 1 128K 128K 40960K 1 0 0 128K
FFS node 15230 3808K 3808K 40960K 16777 0 0 256
MFS node 1 1K 1K 40960K 10 0 0 64,256
UFS ihash 1 128K 128K 40960K 1 0 0 128K
UFS mount 30 83K 83K 40960K 30 0 0 512,2K,4K,8K
VM pgdata 1 544K 544K 40960K 1 0 0 512K
ZONE 18 3K 3K 40960K 18 0 0 128
mbuf 1 12K 12K 40960K 1 0 0 16K
Memory Totals: In Use Free Requests
6627K 86K 665065
>
> To see if your KVM has filled up.
>
> -Matt
>
> Matthew Dillon
> <dillon@backplane.com>
>
> :
> :The Errors are are all resultion with the same trigger.
> :Running squid and doing several lookups with wget.
> :I have tried a current SNAP 1999-01-12
> :and tried the Stable-SNAP 1999-02-02 with the same problems.
> :...
> :#4 0xf01eb372 in trap (frame={tf_es = 16, tf_ds = -10616816, tf_edi = 0,
> : tf_esi = -226674688, tf_ebp = -10589200, tf_isp = -10589256,
> : tf_ebx = 20480, tf_edx = 5, tf_ecx = 5120, tf_eax = 0, tf_trapno = 12,
> : tf_err = 2, tf_eip = -266426457, tf_cs = 8, tf_eflags = 66054,
> : tf_esp = -250478592, tf_ss = -266515610}) at ../../i386/i386/trap.c:437
> :#5 0xf01ea7a7 in generic_bzero ()
> :#6 0xf015e6d8 in getnewvnode (tag=VT_UFS, mp=0xf2734e00, vops=0xf2667300,
> : vpp=0xff5e6c7c) at ../../vm/vm_zone.h:85
> :#7 0xf01bdb4d in ffs_vget (mp=0xf2734e00, ino=222414, vpp=0xff5e6ccc)
> : at ../../ufs/ffs/ffs_vfsops.c:1082
> :#8 0xf01b7ee1 in ffs_valloc (pvp=0xffbbc440, mode=33188, cred=0xf2805300,
> : vpp=0xff5e6ccc) at ../../ufs/ffs/ffs_alloc.c:595
> :#9 0xf01c5901 in ufs_makeinode (mode=33188, dvp=0xffbbc440, vpp=0xff5e6f10,
> : cnp=0xff5e6f24) at ../../ufs/ufs/ufs_vnops.c:2082
> :#10 0xf01c316a in ufs_create (ap=0xff5e6e2c) at ../../ufs/ufs/ufs_vnops.c:179
> :#11 0xf01c5ad5 in ufs_vnoperate (ap=0xff5e6e2c)
> : at ../../ufs/ufs/ufs_vnops.c:2294
> :#12 0xf0164ddb in vn_open (ndp=0xff5e6f00, fmode=1550, cmode=420)
> : at vnode_if.h:83
> :#13 0xf0161b8d in open (p=0xff5d2780, uap=0xff5e6f94)
> : at ../../kern/vfs_syscalls.c:935
> :...
> :--
> : B.Walter
>
--
B.Walter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990204083333.36857>