panic (kmem_map too small) with smbfs
Brian Fundakowski Feldman
green at freebsd.org
Mon May 16 13:02:26 PDT 2005
On Sun, May 15, 2005 at 11:47:16PM +0200, Ivan Voras wrote:
> It happened again. Same symptomps but very different backtrace of the
> core:
>
> beastie:/usr/obj/usr/src/sys/BEASTIE> kgdb kernel.debug
> /radni/Temp/vmcore.34
> [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 "i386-marcel-freebsd".
> #0 doadump () at pcpu.h:159
> 159 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) bt
> #0 doadump () at pcpu.h:159
> #1 0xc0541e3e in boot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:410
> #2 0xc0542189 in panic (fmt=0xc071a72b "kmem_malloc(%ld): kmem_map too
> small: %ld total allocated") at /usr/src/sys/kern/kern_shutdown.c:566
> #3 0xc067c70b in kmem_malloc (map=0xc103b0c0, size=12288, flags=2) at
> /usr/src/sys/vm/vm_kern.c:299
> #4 0xc068fce7 in page_alloc (zone=0x0, bytes=0, pflag=0x0, wait=0) at
> /usr/src/sys/vm/uma_core.c:957
> #5 0xc0692982 in uma_large_malloc (size=12288, wait=2) at
> /usr/src/sys/vm/uma_core.c:2644
> #6 0xc05350ee in malloc (size=12288, type=0xc0740360, flags=2) at
> /usr/src/sys/kern/kern_malloc.c:300
> #7 0xc0563e6b in sbuf_new (s=0xc1b59a80, buf=0x0, length=0, flags=0) at
> /usr/src/sys/kern/subr_sbuf.c:187
> #8 0xc05c1528 in ifconf (cmd=3221776676, data=0xc16dd740 "") at
> /usr/src/sys/net/if.c:1537
> #9 0xc05c1131 in ifioctl (so=0xc22d1798, cmd=3221776676, data=0xc16dd740
> "", td=0xc1915000) at /usr/src/sys/net/if.c:1358
> #10 0xc0570374 in soo_ioctl (fp=0x0, cmd=3221776676, data=0xc16dd740,
> active_cred=0xc14b1d80, td=0xc1915000) at
> /usr/src/sys/kern/sys_socket.c:214
> #11 0xc0568ee8 in ioctl (td=0xc1915000, uap=0xd47ebd14) at file.h:257
> #12 0xc06cfc70 in syscall (frame=
> {tf_fs = -1066729425, tf_es = 47, tf_ds = 47, tf_edi = -1077945136,
> tf_esi = -1077940584, tf_ebp = -1077945208, tf_isp = -729891468, tf_ebx =
> 1116192741, tf_edx = -1077953424, tf_ecx = 0, tf_eax = 54, tf_trapno = 0,
> tf_err = 2, tf_eip = 675713679, tf_cs = 31, tf_eflags = 658, tf_esp =
> -1077953476, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1009
> #13 0xc06bcd3f in Xint0x80_syscall () at
> /usr/src/sys/i386/i386/exception.s:201
> #14 0xc06b002f in scioctl (dev=Cannot access memory at address 0xbfbfdc90
> ) at /usr/src/sys/dev/syscons/syscons.c:727
> Previous frame inner to this frame (corrupt stack?)
>
> As advised, I logged vmstat -m output. This is the log file:
> http://geri.cc.fer.hr/~ivoras/vmstat.log.bz2
>
> I logged vmstat -m via crontab every 10 minutes since I started working
> until the panic. As far as I can tell, there's nothing bad going on, or if
> there is, it happend just before the crash.
BTW, if nothing bad seems to be happening there, there may still be
bad things happening that would be reported by vmstat -z output
(note that vmstat -z will also supersede netstat -m output).
--
Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\
<> green at FreeBSD.org \ The Power to Serve! \
Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
More information about the freebsd-current
mailing list