Re: panic (kmem_map too small) with smbfs

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.

-- 
Every sufficiently advanced magic is indistinguishable from technology
    - Arthur C Anticlarke