Bug #1654
closed
panic: kmem_slab_alloc(): kernel_map ran out of space!
0%
Description
Perhaps related to
http://leaf.dragonflybsd.org/mailarchive/kernel/2010-01/msg00002.html
and
http://leaf.dragonflybsd.org/mailarchive/commits/2010-01/msg00061.html
I just got a panic tonight:
Reading symbols from /home/var.crash/kern.27...done.
Unread portion of the kernel message buffer:
panic: kmem_slab_alloc(): kernel_map ran out of space!
mp_lock = 00000001; cpuid = 1
Trace beginning at frame 0xf23d5ae0
panic(f23d5b04,f47209f0,20000,102,f23d5b24) at panic+0x14d
panic(c0385830,0,4000,20000,4) at panic+0x14d
kmem_slab_alloc(0,ab,ff808000,9,50) at kmem_slab_alloc+0x159
kmalloc(4c,c03b84a0,102,0,f23d5c7c) at kmalloc+0x628
cache_alloc(0,0,db59cd60,daeac918,ff808000) at cache_alloc+0x18
cache_nlookup(f23d5c7c,f23d5bd8,f23d5c7c,f23d5c7c,0) at
cache_nlookup+0x3f4
nlookup(f23d5c7c,0,f23d5c7c,1,f23d5cc0) at nlookup+0x23b
kern_stat(f23d5c7c,f23d5c14,1d6741,0,1) at kern_stat+0xf
sys_lstat(f23d5cf0,6,246ebe,0,f255b558) at sys_lstat+0xad
syscall2(f23d5d40) at syscall2+0x3eb
Xint0x80_syscall() at Xint0x80_syscall+0x36
boot() called on cpu#1
Uptime: 8h16m54s
Physical memory: 2043 MB
Dumping 368 MB: 353 337 321 305 289 273 257 241 225 209 193 177 161 145
129 113 97 81 65 49 33 17 1
get_mycpu (di=0xc044e140) at ./machine/thread.h:83
83 __asm ("movl %%fs:globaldata,%0" : "=r" (gd) :
"m"(_mycpu__dummy));
(kgdb) bt
#0 _get_mycpu (di=0xc044e140) at ./machine/thread.h:83
#1 md_dumpsys (di=0xc044e140) at
/usr/src/sys/platform/pc32/i386/dump_machdep.c:264
#2 0xc01c5bbe in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:838
#3 0xc01c6190 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:387
#4 0xc01c66ee in panic (fmt=0xc0385830 "kmem_slab_alloc(): kernel_map
ran out of space!") at /usr/src/sys/kern/kern_shutdown.c:744
#5 0xc01c31c8 in kmem_slab_alloc (size=131072, align=131072, flags=258)
at /usr/src/sys/kern/kern_slaballoc.c:1139
#6 0xc01c4385 in kmalloc (size=80, type=0xc03b84a0, flags=<value
optimized out>) at /usr/src/sys/kern/kern_slaballoc.c:658
#7 0xc02119cb in cache_alloc (nlen=0) at
/usr/src/sys/kern/vfs_cache.c:590
#8 0xc0213e2d in cache_nlookup (par_nch=0xf23d5c7c, nlc=0xf23d5bd8) at
/usr/src/sys/kern/vfs_cache.c:2253
#9 0xc021d4ce in nlookup (nd=0xf23d5c7c) at
/usr/src/sys/kern/vfs_nlookup.c:513
#10 0xc02253d2 in kern_stat (nd=0xf23d5c7c, st=0xf23d5c14) at
/usr/src/sys/kern/vfs_syscalls.c:2596
#11 0xc022af9d in sys_lstat (uap=0xf23d5cf0) at
/usr/src/sys/kern/vfs_syscalls.c:2668
#12 0xc033f6c9 in syscall2 (frame=0xf23d5d40) at
/usr/src/sys/platform/pc32/i386/trap.c:1361
#13 0xc032a6e6 in Xint0x80_syscall () at
/usr/src/sys/platform/pc32/i386/exception.s:876
#14 0x0000001f in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
The end of kmapinfo's output:
-----------------------------------------------
Total empty space: 184K
Total used space: 1048392K
Indeed it appears to be out of memory. Are 32-bit users hosed?
Kernel and core are being uploaded to leaf:~pavalos/crash/*27
--Peter
Updated by rumcic almost 15 years ago
Peter Avalos wrote:
<snip>
The end of kmapinfo's output:
-----------------------------------------------
Total empty space: 184K
Total used space: 1048392KIndeed it appears to be out of memory. Are 32-bit users hosed?
Kernel and core are being uploaded to leaf:~pavalos/crash/*27
--Peter
Got a panic here as well, tried decreasing kern.maxfiles back to kern.maxproc*2
but I could still panic the machine, I guess it's more got to do with commit
cf1bb2a83 (just a guess, have no clue)?
Or maybe I would just need to set kern.maxfiles at boot-time instead while the
machine is running (would it make a difference?)?
--
Regards,
Rumko
Updated by dillon almost 15 years ago
:Perhaps related to
:http://leaf.dragonflybsd.org/mailarchive/kernel/2010-01/msg00002.html
:and
:http://leaf.dragonflybsd.org/mailarchive/commits/2010-01/msg00061.html
:
:I just got a panic tonight:
:Reading symbols from /home/var.crash/kern.27...done.
:
:-----------------------------------------------
:Total empty space: 184K
:Total used space: 1048392K
:
:Indeed it appears to be out of memory. Are 32-bit users hosed?
:
:Kernel and core are being uploaded to leaf:~pavalos/crash/*27
:
:--Peter
I've got my work cut out for me today.At the very least we will be able to move some of the zalloc zones
used by the network over to just using kmalloc(). That is certainly
a contributor as ZONE_INTERRUPT zalloc zones reserve KVA (aka the
maxfiles change). I want to keep the maxfiles change itself.tcpcb, udpcb, and ripcb are eating a ton of KVA (tcpcb mainly).
tcpcb alone is eating 80MB of KVA.-Matt
Updated by sjg over 14 years ago
We have freed up almost 100MB of KVA for i386 since 2.4, this should be fixed.
Please reopen if this can be reproduced on recent master.