panic: kmem_malloc(131072): kmem_map too small (AMD64)

From: Larry Rosenman <ler_at_lerctr.org>
Date: Fri, 21 Sep 2007 10:32:23 -0500 (CDT)
I'm a heavy ZFS user, and got the following panic on 2007-09-18 source/world:

# kgdb -c vmcore.1 /usr/obj/usr/src/sys/BORG/kernel.debug
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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 "amd64-marcel-freebsd".

Unread portion of the kernel message buffer:
panic: kmem_malloc(131072): kmem_map too small: 333647872 total allocated
cpuid = 2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
panic() at panic+0x17a
kmem_malloc() at kmem_malloc+0x49a
uma_large_malloc() at uma_large_malloc+0x4a
malloc() at malloc+0x12d
arc_get_data_buf() at arc_get_data_buf+0x36e
arc_buf_alloc() at arc_buf_alloc+0xe4
arc_read() at arc_read+0xfa
dbuf_prefetch() at dbuf_prefetch+0x137
dmu_zfetch_dofetch() at dmu_zfetch_dofetch+0xd4
dmu_zfetch() at dmu_zfetch+0x616
dbuf_read() at dbuf_read+0x31f
dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0xe9
dmu_buf_hold_array() at dmu_buf_hold_array+0x62
dmu_read_uio() at dmu_read_uio+0x3f
zfs_freebsd_read() at zfs_freebsd_read+0x576
vn_read() at vn_read+0x17a
dofileread() at dofileread+0xa1
kern_readv() at kern_readv+0x4c
read() at read+0x54
syscall() at syscall+0x1ce
Xfast_syscall() at Xfast_syscall+0xab
--- syscall (3, FreeBSD ELF64, read), rip = 0x80158835c, rsp = 0x7fffff9fd058, rbp = 0 ---
Uptime: 2d6h22m6s
Physical memory: 4085 MB
Dumping 1305 MB: 1290 1274 1258 1242 1226 1210 1194 1178 1162 1146 1130 1114 1098 1082 1066 1050 1034 1018 1002 986 970 954 938 922 906 890 874 858 842 826 810 794 778 762 746 730 714 698 682 666 650 634 618 602 586 570 554 538 522 506 490 474 458 442 426 410 394 378 362 346 330 314 298 282 266 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10

#0  doadump () at pcpu.h:194
194     pcpu.h: No such file or directory.
         in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:194
#1  0xffffffff802e3c65 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2  0xffffffff802e40d7 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3  0xffffffff804d138a in kmem_malloc (map=0xffffff00010000f8, size=131072, flags=2) at /usr/src/sys/vm/vm_kern.c:305
#4  0xffffffff804ca53a in uma_large_malloc (size=131072, wait=2) at /usr/src/sys/vm/uma_core.c:2709
#5  0xffffffff802d65ed in malloc (size=131072, mtp=0xffffffff8095f5c0, flags=2) at /usr/src/sys/kern/kern_malloc.c:364
#6  0xffffffff80900a8e in ?? ()
#7  0x000000000000a125 in ?? ()
#8  0xffffff00180f90f0 in ?? ()
#9  0xffffff00046fa000 in ?? ()
#10 0xffffff006cc14898 in ?? ()
#11 0x0000000000020000 in ?? ()
#12 0xffffff00046fa000 in ?? ()
#13 0xffffffffb243c4f0 in ?? ()
#14 0xffffffff80900ca4 in ?? ()
#15 0x0000000000000000 in ?? ()
#16 0xffffffff94cd1d00 in ?? ()
#17 0x0000000000000070 in ?? ()
#18 0x0000000000000000 in ?? ()
#19 0xffffffffb243c580 in ?? ()
#20 0xffffffff80901bda in ?? ()
#21 0xffffffffb243c5e0 in ?? ()
#22 0xffffffff802eb070 in _sx_xunlock (sx=0xffffffff809633c0, file=0x20000 <Address 0x20000 out of bounds>, line=403673328)
---Type <return> to continue, or q <return> to quit---
     at /usr/src/sys/kern/kern_sx.c:309
Previous frame inner to this frame (corrupt stack?)
(kgdb)

I have the core available, and am more than willing to give access to the box.

I'm not sure exactly what may have triggered it, but this is the first ZFS panic I've seen.



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 512-248-2683                 E-Mail: ler_at_lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
Received on Fri Sep 21 2007 - 13:47:42 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:17 UTC