:% vmstat -m -M /var/qmail/crash/vmcore.6
:Memory Totals: In Use Free Requests
: 17408K 137K 7909365
:% vmstat -z -M /var/qmail/crash/vmcore.6
:
:ZONE used total mem-use
:PIPE 55 408 8/63K
:SWAPMETA 0 0 0/0K
:tcpcb 303 371 160/197K
:unpcb 4 128 0/8K
:ripcb 0 21 0/3K
:tcpcb 0 0 0/0K
:udpcb 41 84 7/15K
:socket 354 441 66/82K
:KNOTE 1 128 0/8K
:NFSNODE 99464 99480 31082/31087K
:NFSMOUNT 26 35 13/18K
:VNODE 105046 105046 19696/19696K
:NAMEI 2 48 2/48K
:VMSPACE 97 320 18/60K
:PROC 101 294 41/119K
:DP fakepg 0 0 0/0K
:PV ENTRY 33850 524263 925/14335K
:MAP ENTRY 1057 2593 49/121K
:KMAP ENTRY 824 1148 38/53K
:MAP 7 10 0/1K
:VM OBJECT 66326 66406 6218/6225K
:------------------------------------------
:TOTAL 58330/72146K
:
:So why is zalloc dying when it looks like only about 90 megs of
:kernel memory is allocated?
Are those active vnodes or cached vnodes? What is kern.maxvnodes
set to?
Also, what's the full vmstat -m output on the crash dump?
:Anyhow, I've added a check in getnewvnode to return ENOMEM if zalloc
:fails, my concern is that other parts of the kernel are going to
:blow up immediately after that is caught because it looks like
:the majority of places don't expect zalloc to fail.
:
:Any suggestions will be helpful, any requests for more information
:will happily be attempted.
:
:thanks,
:-Alfred
Well, there's definitely some kind of limit being hit here. You
have to figure out what it is first. Print out the zalloc zone
structure being used to see why it is returning NULL. Maybe it
has hit it's max count or something and the bug is that the zalloc
zone isn't scaled with kern.maxvnodes, or something like that.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
