Re: panic (kmem_map too small) with smbfs

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.                       \,,,,,,,,,,,,,,,,,,,,,,\