From nobody@FreeBSD.org  Sun Dec 26 11:11:04 2004
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 93C7216A4CE
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 26 Dec 2004 11:11:04 +0000 (GMT)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 3872643D1D
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 26 Dec 2004 11:11:04 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id iBQBB3Nj003166
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 26 Dec 2004 11:11:03 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id iBQBB30H003165;
	Sun, 26 Dec 2004 11:11:03 GMT
	(envelope-from nobody)
Message-Id: <200412261111.iBQBB30H003165@www.freebsd.org>
Date: Sun, 26 Dec 2004 11:11:03 GMT
From: Rob Swindell <rob@synchro.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: panic: kmem_malloc(4096): kmem_map too small
X-Send-Pr-Version: www-2.3

>Number:         75510
>Category:       kern
>Synopsis:       panic: kmem_malloc(4096): kmem_map too small
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Dec 26 11:20:17 GMT 2004
>Closed-Date:    Mon Nov 19 08:19:09 UTC 2007
>Last-Modified:  Mon Nov 19 08:19:09 UTC 2007
>Originator:     Rob Swindell
>Release:        5.3-RELEASE
>Organization:
Synchronet
>Environment:
FreeBSD devil.synchro.net 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Sat Dec 25 02:42:54 PST 2004     root@devil.synchro.net:/usr/src/sys/i386/compile/MYKERNEL  i386
  
>Description:
When running a multi-threaded server application (http://www.synchro.net), accessing configuration and data files on an smbfs-mounted volume, after 4-8 hours, I get the following panic (routinely):

panic:  kmem_malloc(4096): kmem_map too small: 40898560 total allocated

I've seen another PR related to a panic like this one, but it was in relation to a system with 4GB+ of RAM. This particular system only has 128MB of RAM. Here is a current "top" output at the time of one of the panics:

last pid:  6429;  load averages:  0.09,  0.07,  0.21    up 0+07:27:31  05:52:23
84 processes:  2 running, 57 sleeping, 25 waiting
CPU states:  0.4% user,  0.0% nice,  3.5% system,  2.3% interrupt, 93.8% idle
Mem: 31M Active, 2652K Inact, 47M Wired, 1556K Cache, 22M Buf, 35M Free
Swap: 231M Total, 88K Used, 231M Free

  PID USERNAME PRI NICE   SIZE    RES STATE    TIME   WCPU    CPU COMMAND
 3158 root      20    0 19928K 17596K kserel  22:14  0.00%  0.00% sbbs
  583 root      96    0  6092K  2172K select   0:01  0.00%  0.00% sshd
 1298 root      96    0  6092K  2168K select   0:01  0.00%  0.00% sshd
  529 root      96    0  6092K  2152K select   0:01  0.00%  0.00% sshd
  476 root      96    0  6092K  1856K select   0:14  0.00%  0.00% sshd
  379 root      96    0  3360K  1560K select   0:00  0.00%  0.00% sshd
  528 root      96    0  2296K  1308K RUN      1:23  0.00%  0.00% top
 1314 root       8    0  2208K  1616K wait     0:00  0.00%  0.00% bash
  586 root       5    0  2204K  1620K ttyin    0:00  0.00%  0.00% bash
  532 root       8    0  2204K  1580K wait     0:00  0.00%  0.00% bash
  479 root       8    0  2204K  1524K wait     0:00  0.00%  0.00% bash
  218 root      96    0  1784K  1048K select   0:01  0.00%  0.00% dhclient
  392 root       8    0  1356K   860K nanslp   0:00  0.00%  0.00% cron
  268 root      96    0  1312K   760K select   0:08  0.00%  0.00% syslogd
  465 root       5    0  1280K   772K ttyin    0:00  0.00%  0.00% getty
  471 root       5    0  1280K   772K ttyin    0:00  0.00%  0.00% getty
  470 root       5    0  1280K   772K ttyin    0:00  0.00%  0.00% getty
  468 root       5    0  1280K   772K ttyin    0:00  0.00%  0.00% getty
  467 root       5    0  1280K   772K ttyin    0:00  0.00%  0.00% getty
  469 root       5    0  1280K   772K ttyin    0:00  0.00%  0.00% getty
  466 root       5    0  1280K   772K ttyin    0:00  0.00%  0.00% getty
 1611 root       5    0  1280K   764K ttyin    0:00  0.00%  0.00% getty
  343 root      96    0  1236K   656K select   0:00  0.00%  0.00% usbd
  428 root      96    0  1232K   656K select   0:00  0.00%  0.00% moused
 3500 root       4    0  1216K   580K kqread   0:00  0.00%  0.00% tail
  167 root      20    0  1184K   572K pause    0:00  0.00%  0.00% adjkerntz
    1 root       8    0   740K   220K wait     0:00  0.00%  0.00% init
  248 root     111    0   516K   224K select   0:00  0.00%  0.00% devd
   11 root     112    0     0K    12K RUN    340:17 89.36% 89.36% idle
  407 root       8    0     0K    12K 90idle   4:01  0.93%  0.93% smbiod0
   27 root     -28 -147     0K    12K WAIT    14:22  0.15%  0.15% swi5: clock s
   29 root     -44 -163     0K    12K WAIT     2:41  0.00%  0.00% swi1: net
   21 root     -68 -187     0K    12K WAIT     2:40  0.00%  0.00% irq10: de0 uh
   30 root      76    0     0K    12K -        0:38  0.00%  0.00% yarrow
   36 root     -24 -143     0K    12K WAIT     0:14  0.00%  0.00% swi6:+
   40 root     171   52     0K    12K pgzero   0:09  0.00%  0.00% pagezero
   42 root      20    0     0K    12K syncer   0:07  0.00%  0.00% syncer
    4 root      -8    0     0K    12K -        0:07  0.00%  0.00% g_down

Here's the top output at the time of another such panic:

last pid:  2904;  load averages:  0.13,  0.11,  0.08                                         

         up 0+01:35:27  14:39:41
75 processes:  2 running, 48 sleeping, 25 waiting
CPU states:  0.4% user,  0.0% nice,  5.4% system,  2.3% interrupt, 91.8% idle
Mem: 22M Active, 7184K Inact, 47M Wired, 1188K Cache, 22M Buf, 40M Free
Swap: 231M Total, 231M Free

  PID USERNAME PRI NICE   SIZE    RES STATE    TIME   WCPU    CPU COMMAND
  474 root      20    0 11908K  9956K kserel   4:10  0.00%  0.00% sbbs
  482 root      96    0  6092K  2240K select   0:03  0.00%  0.00% sshd
  470 root      96    0  6092K  2236K select   0:00  0.00%  0.00% sshd
  380 root      96    0  3360K  1936K select   0:00  0.00%  0.00% sshd
  487 root       8    0  2208K  1576K wait     0:00  0.00%  0.00% bash
  473 root       8    0  2208K  1568K wait     0:00  0.00%  0.00% bash
  488 root      96    0  2280K  1316K RUN      0:17  0.00%  0.00% top
  216 root      96    0  1784K  1064K select   0:00  0.00%  0.00% dhclient
  393 root       8    0  1356K   916K nanslp   0:00  0.00%  0.00% cron
  462 root       5    0  1280K   808K ttyin    0:00  0.00%  0.00% getty
  463 root       5    0  1280K   808K ttyin    0:00  0.00%  0.00% getty
  469 root       5    0  1280K   808K ttyin    0:00  0.00%  0.00% getty
  466 root       5    0  1280K   808K ttyin    0:00  0.00%  0.00% getty
  465 root       5    0  1280K   808K ttyin    0:00  0.00%  0.00% getty
  468 root       5    0  1280K   808K ttyin    0:00  0.00%  0.00% getty
  467 root       5    0  1280K   808K ttyin    0:00  0.00%  0.00% getty
  464 root       5    0  1280K   808K ttyin    0:00  0.00%  0.00% getty
  266 root      96    0  1312K   800K select   0:02  0.00%  0.00% syslogd
  342 root      96    0  1236K   688K select   0:00  0.00%  0.00% usbd
  429 root     118    0  1232K   664K select   0:00  0.00%  0.00% moused
  165 root      20    0  1184K   580K pause    0:00  0.00%  0.00% adjkerntz
    1 root       8    0   740K   244K wait     0:00  0.00%  0.00% init
  246 root     111    0   516K   224K select   0:00  0.00%  0.00% devd
   11 root     104    0     0K    12K RUN     59:07 90.23% 90.23% idle
  408 root       8    0     0K    12K 90idle   1:11  0.29%  0.29% smbiod0
   27 root     -44 -163     0K    12K WAIT     0:42  0.10%  0.10% swi1: net
   28 root     -28 -147     0K    12K WAIT     1:45  0.00%  0.00% swi5: clock sio
   21 root     -68 -187     0K    12K WAIT     1:19  0.00%  0.00% irq10: de0 uhci0
   30 root      76    0     0K    12K -        0:09  0.00%  0.00% yarrow
   40 root     171   52     0K    12K pgzero   0:04  0.00%  0.00% pagezero
   32 root     -24 -143     0K    12K WAIT     0:04  0.00%  0.00% swi6:+
   43 root      20    0     0K    12K syncer   0:01  0.00%  0.00% syncer
    3 root      -8    0     0K    12K -        0:01  0.00%  0.00% g_up
    4 root      -8    0     0K    12K -        0:01  0.00%  0.00% g_down
   45 root      -8    0     0K    12K -        0:01  0.00%  0.00% schedcpu
    2 root      -8    0     0K    12K -        0:01  0.00%  0.00% g_event
   25 root     -64 -183     0K    12K WAIT     0:01  0.00%  0.00% irq14: ata0
  410 root       8    0     0K    12K 90idle   0:00  0.00%  0.00% smbiod1
   41 root     -16    0     0K    12K psleep   0:00  0.00%  0.00% bufdaemon
   42 root      -4    0     0K    12K vlruwt   0:00  0.00%  0.00% vnlru
    7 root      -8    0     0K    12K -        0:00  0.00%  0.00% fdc0


Here is the mbuf allocation status not too long before a panic:

[devil:~]# netstat -m
108 mbufs in use
34/4800 mbuf clusters in use (current/max)
0/3/1456 sfbufs in use (current/peak/max)
95 KBytes allocated to network
0 requests for sfbufs denied
0 requests for sfbufs delayed
2 requests for I/O initiated by sendfile
57 calls to protocol drain routines

Here's a /var/crash/info file for a recent panic:

  Architecture: i386
  Architecture version: 1
  Dump length: 134205440B (127 MB)
  Blocksize: 512
  Dumptime: Sat Dec 25 14:39:42 2004
  Hostname: devil.synchro.net
  Versionstring: FreeBSD 5.3-RELEASE #0: Sat Dec 25 02:42:54 PST 2004
    root@devil.synchro.net:/usr/src/sys/i386/compile/MYKERNEL
  Panicstring: kmem_malloc(4096): kmem_map too small: 40898560 total allocated
  Bounds: 0

Here's a kgdb backtrace from that same panic:

(kgdb) bt
#0  doadump () at pcpu.h:159
#1  0xc05fdc49 in boot (howto=260) at ../../../kern/kern_shutdown.c:397
#2  0xc05fdf05 in panic (
    fmt=0xc07c38d3 "kmem_malloc(%ld): kmem_map too small: %ld total allocated")
    at ../../../kern/kern_shutdown.c:553
#3  0xc06fc8d9 in kmem_malloc (map=0xc103a0c0, size=4096, flags=258)
    at ../../../vm/vm_kern.c:300
#4  0xc070b7c2 in page_alloc (zone=0xc1044d80, bytes=4096, pflag=0x0, wait=258)
    at ../../../vm/uma_core.c:935
#5  0xc070b301 in slab_zalloc (zone=0xc1044d80, wait=258)
    at ../../../vm/uma_core.c:805
#6  0xc070ca54 in uma_zone_slab (zone=0xc1044d80, flags=2)
    at ../../../vm/uma_core.c:1962
#7  0xc070cc74 in uma_zalloc_bucket (zone=0xc1044d80, flags=2)
    at ../../../vm/uma_core.c:2071
#8  0xc070c900 in uma_zalloc_arg (zone=0xc1044d80, udata=0x0, flags=2)
    at ../../../vm/uma_core.c:1889
#9  0xc06455ba in cache_enter (dvp=0xc17afb58, vp=0xc17dc318, cnp=0xcc83fa48)
    at uma.h:274
#10 0xc1575310 in ?? ()
#11 0xc17afb58 in ?? ()
#12 0xc17dc318 in ?? ()
#13 0xcc83fa48 in ?? ()

I don't know for sure that this is an smbfs-related problem, but I have my suspicions. I don't know if it's any clue, but for every file close(), I get the following error: "smb_maperror: Unmapped error 1:158".

Merry Christmas!
>How-To-Repeat:
Run Synchronet (http://www.synchro.net) (or probably any other multi-threaded server) with the configuration and data files stored in an smbfs-mounted directory.
>Fix:
      
>Release-Note:
>Audit-Trail:

From: Kris Kennaway <kris@obsecurity.org>
To: Rob Swindell <rob@synchro.net>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/75510: panic: kmem_malloc(4096): kmem_map too small
Date: Mon, 27 Dec 2004 11:17:44 -0800

 On Sun, Dec 26, 2004 at 11:11:03AM +0000, Rob Swindell wrote:
 > 
 > >Number:         75510
 > >Category:       misc
 > >Synopsis:       panic: kmem_malloc(4096): kmem_map too small
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       high
 > >Responsible:    freebsd-bugs
 > >State:          open
 > >Quarter:        
 > >Keywords:       
 > >Date-Required:
 > >Class:          sw-bug
 > >Submitter-Id:   current-users
 > >Arrival-Date:   Sun Dec 26 11:20:17 GMT 2004
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Rob Swindell
 > >Release:        5.3-RELEASE
 > >Organization:
 > Synchronet
 > >Environment:
 > FreeBSD devil.synchro.net 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Sat Dec 25 02:42:54 PST 2004     root@devil.synchro.net:/usr/src/sys/i386/compile/MYKERNEL  i386
 >   
 > >Description:
 > When running a multi-threaded server application (http://www.synchro.net), accessing configuration and data files on an smbfs-mounted volume, after 4-8 hours, I get the following panic (routinely):
 > 
 > panic:  kmem_malloc(4096): kmem_map too small: 40898560 total allocated
 > 
 > I've seen another PR related to a panic like this one, but it was in
 > relation to a system with 4GB+ of RAM. This particular system only
 > has 128MB of RAM. Here is a current "top" output at the time of one
 > of the panics:
 
 The same explanation applies; your application is causing your kernel
 to run out of KVM.  Since you only have 128MB you don't have much room
 to increase the defaults as described in other PRs and emails about
 this topic, so the best solution is to add more RAM.
 
 Kris

From: Sharon Hurd <dominoe@sasktel.net>
To: freebsd-gnats-submit@FreeBSD.org, rob@synchro.net
Cc:  
Subject: Re: misc/75510: panic: kmem_malloc(4096): kmem_map too small
Date: Mon, 27 Dec 2004 13:47:03 -0600

 This is a multi-part message in MIME format.
 
 --Boundary_(ID_aWXkwFL+ok7p/STGmaBrHA)
 Content-type: text/plain; charset=iso-8859-1
 Content-transfer-encoding: 7BIT
 
 The program in question (Synchronet) does not exhibit this behaviour when using NFS or a local UFS or UFS2 filesystem... I've been running it for a couple years now on both setups without issue.  Further, it doesn't use the kvm interface itself.  Does smbfs really need that much kernel memory?  This sounds somewhat like a memory leak in smbfs... not that I see offhand where it uses kvm either.
 
 
 --Boundary_(ID_aWXkwFL+ok7p/STGmaBrHA)
 Content-type: text/html; charset=iso-8859-1
 Content-transfer-encoding: 7BIT
 
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 <HTML><HEAD>
 <META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
 <META content="MSHTML 6.00.2800.1479" name=GENERATOR>
 <STYLE></STYLE>
 </HEAD>
 <BODY bgColor=#ffffff>
 <DIV><FONT face=Arial size=2>The program in question (Synchronet) does not 
 exhibit this behaviour when using NFS or a local UFS or UFS2 filesystem... I've 
 been running it for a couple years now on both setups without issue.&nbsp; 
 Further, it doesn't use the kvm interface itself.&nbsp; Does smbfs really need 
 that much kernel memory?&nbsp; This sounds somewhat like a memory leak in 
 smbfs... not that I see offhand where it uses kvm either.</FONT></DIV>
 <DIV>&nbsp;</DIV>
 <DIV><FONT face=Arial size=2></FONT><FONT face=Arial 
 size=2></FONT>&nbsp;</DIV></BODY></HTML>
 
 --Boundary_(ID_aWXkwFL+ok7p/STGmaBrHA)--

From: Sharon Hurd <dominoe@sasktel.net>
To: freebsd-gnats-submit@FreeBSD.org, rob@synchro.net
Cc:  
Subject: Re: misc/75510: panic: kmem_malloc(4096): kmem_map too small
Date: Mon, 27 Dec 2004 14:22:22 -0600

 Damn, sorry about that last, using my wifes system.  I'll summarize here
 so the previous can be deleted.
 
 Synchronet doesn't use kvm itself... it runs well on FreeBSD 4.10 systems
 with 64MB of RAM
 using UFS and 5.3 systems using NFS with 64MB of RAM.  These issues occur
 only when the
 file system that is being used is smbfs.  A quick grep through the smbfs and
 netsmb sources don't
 show any kvm usage either... but I would tend to give a quick off-the-cuff
 diagnosis as a memory
 leak in smbfs.
 

From: "Rob Swindell" <rob@synchro.net>
To: <freebsd-gnats-submit@FreeBSD.org>,
	"Rob Swindell" <rob@synchro.net>
Cc:  
Subject: Re: misc/75510: panic: kmem_malloc(4096): kmem_map too small
Date: Mon, 27 Dec 2004 23:57:05 -0800

 Here's another capture of netstat -m (shortly before the panic), top (at the
 time of the panic), /var/crash/info and vmcore kgdb backtrace.
 
 [devil:~]# netstat -m
 162 mbufs in use
 33/4800 mbuf clusters in use (current/max)
 0/3/1456 sfbufs in use (current/peak/max)
 106 KBytes allocated to network
 0 requests for sfbufs denied
 0 requests for sfbufs delayed
 0 requests for I/O initiated by sendfile
 105 calls to protocol drain routines
 
 
 last pid: 10117;  load averages:  0.01,  0.04,  0.16
 up 2+08:09:41  22:50:26
 77 processes:  2 running, 50 sleeping, 25 waiting
 CPU states:  1.6% user,  0.0% nice,  4.7% system,  1.6% interrupt, 92.2% idle
 Mem: 26M Active, 3536K Inact, 46M Wired, 840K Cache, 22M Buf, 40M Free
 Swap: 231M Total, 8K Used, 231M Free
 
   PID USERNAME PRI NICE   SIZE    RES STATE    TIME   WCPU    CPU COMMAND
  7757 root      20    0 11908K  9988K kserel   1:58  0.00%  0.00% sbbs
  8161 root      96    0  6092K  2288K select   0:00  0.00%  0.00% sshd
  7985 root      96    0  6092K  2276K select   0:02  0.00%  0.00% sshd
   654 root      96    0  6092K  2152K select   0:01  0.00%  0.00% sshd
   377 root      96    0  3360K  1612K select   0:00  0.00%  0.00% sshd
  7992 root       8    0  2208K  1600K wait     0:00  0.00%  0.00% bash
  8176 root       5    0  2208K  1600K ttyin    0:00  0.00%  0.00% bash
   657 root       8    0  2212K  1584K wait     0:00  0.00%  0.00% bash
  7997 root      96    0  2292K  1336K RUN      0:10  0.00%  0.00% top
   215 root      96    0  1784K  1060K select   0:06  0.00%  0.00% dhclient
   390 root       8    0  1356K   808K nanslp   0:02  0.00%  0.00% cron
   459 root       5    0  1280K   692K ttyin    0:00  0.00%  0.00% getty
   461 root       5    0  1280K   692K ttyin    0:00  0.00%  0.00% getty
   460 root       5    0  1280K   692K ttyin    0:00  0.00%  0.00% getty
   462 root       5    0  1280K   692K ttyin    0:00  0.00%  0.00% getty
   465 root       5    0  1280K   692K ttyin    0:00  0.00%  0.00% getty
   464 root       5    0  1280K   692K ttyin    0:00  0.00%  0.00% getty
   466 root       5    0  1280K   692K ttyin    0:00  0.00%  0.00% getty
   463 root       5    0  1280K   692K ttyin    0:00  0.00%  0.00% getty
   265 root      96    0  1312K   676K select   0:02  0.00%  0.00% syslogd
   426 root     107    0  1232K   600K select   0:00  0.00%  0.00% moused
   341 root      96    0  1236K   592K select   0:01  0.00%  0.00% usbd
   164 root      20    0  1184K   508K pause    0:00  0.00%  0.00% adjkerntz
     1 root       8    0   740K   236K wait     0:00  0.00%  0.00% init
   245 root     111    0   516K   224K select   0:00  0.00%  0.00% devd
    11 root      98    0     0K    12K RUN     54.3H 92.97% 92.97% idle
   405 root       8    0     0K    12K 90idle   0:57  0.15%  0.15% smbiod0
    27 root     -44 -163     0K    12K WAIT     0:33  0.05%  0.05% swi1: net
    28 root     -28 -147     0K    12K WAIT    77:42  0.00%  0.00% swi5: clock
 sio
    43 root      20    0     0K    12K syncer   1:01  0.00%  0.00% syncer
    30 root      76    0     0K    12K -        0:26  0.00%  0.00% yarrow
     4 root      -8    0     0K    12K -        0:21  0.00%  0.00% g_down
     2 root      -8    0     0K    12K -        0:21  0.00%  0.00% g_event
    21 root     -68 -187     0K    12K WAIT     0:20  0.00%  0.00% irq10: de0
 uhci0
     3 root      -8    0     0K    12K -        0:17  0.00%  0.00% g_up
    45 root      -8    0     0K    12K -        0:16  0.00%  0.00% schedcpu
    40 root     171   52     0K    12K pgzero   0:13  0.00%  0.00% pagezero
    32 root     -24 -143     0K    12K WAIT     0:03  0.00%  0.00% swi6:+
    42 root      -4    0     0K    12K vlruwt   0:03  0.00%  0.00% vnlru
    41 root     -16    0     0K    12K psleep   0:02  0.00%  0.00% bufdaemon
    25 root     -64 -183     0K    12K WAIT     0:02  0.00%  0.00% irq14: ata0
 
 Good dump found on device /dev/ad0s1b
   Architecture: i386
   Architecture version: 1
   Dump length: 134205440B (127 MB)
   Blocksize: 512
   Dumptime: Mon Dec 27 22:50:28 2004
   Hostname: devil.synchro.net
   Versionstring: FreeBSD 5.3-RELEASE #0: Sat Dec 25 02:42:54 PST 2004
     root@devil.synchro.net:/usr/src/sys/i386/compile/MYKERNEL
   Panicstring: kmem_malloc(4096): kmem_map too small: 40898560 total allocated
   Bounds: 1
 
 
 (kgdb) bt
 #0  doadump () at pcpu.h:159
 #1  0xc05fdc49 in boot (howto=260) at ../../../kern/kern_shutdown.c:397
 #2  0xc05fdf05 in panic (
     fmt=0xc07c38d3 "kmem_malloc(%ld): kmem_map too small: %ld total allocated")
     at ../../../kern/kern_shutdown.c:553
 #3  0xc06fc8d9 in kmem_malloc (map=0xc103a0c0, size=4096, flags=258)
     at ../../../vm/vm_kern.c:300
 #4  0xc070b7c2 in page_alloc (zone=0xc1044d80, bytes=4096, pflag=0x0, wait=258)
     at ../../../vm/uma_core.c:935
 #5  0xc070b301 in slab_zalloc (zone=0xc1044d80, wait=258)
     at ../../../vm/uma_core.c:805
 #6  0xc070ca54 in uma_zone_slab (zone=0xc1044d80, flags=2)
     at ../../../vm/uma_core.c:1962
 #7  0xc070cc74 in uma_zalloc_bucket (zone=0xc1044d80, flags=2)
     at ../../../vm/uma_core.c:2071
 #8  0xc070c900 in uma_zalloc_arg (zone=0xc1044d80, udata=0x0, flags=2)
     at ../../../vm/uma_core.c:1889
 #9  0xc06455ba in cache_enter (dvp=0xc1dc2a50, vp=0xc1bb4528, cnp=0xcc855a48)
     at uma.h:274
 #10 0xc1593310 in ?? ()
 #11 0xc1dc2a50 in ?? ()
 #12 0xc1bb4528 in ?? ()
 #13 0xcc855a48 in ?? ()
 
 As Stephen stated, the application (Synchronet, aka "sbbs") doesn't use KVM, so
 I don't know how it could be "causing [the] kernel to run out of KVM" as Kris
 claimed. The application requires between 10 and 20MB of memory, there is 128MB
 physical RAM and 256MB of swap available. If the OS can't run the application
 in this configuration without a kernel panic, I hardly see "add more RAM" as a
 viable solution.
 
 Thanks,
 
 -Rob
State-Changed-From-To: open->closed 
State-Changed-By: kmacy 
State-Changed-When: Mon Nov 19 08:16:57 UTC 2007 
State-Changed-Why:  

Submitter's system only has 128MB and smbfs is allocating more memory to the kernel 
than the sysytem can provide. Ideally smbfs would be fixed to be smarter about memory 
management, but there are more fundamental issues that would be fixed first. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=75510 
>Unformatted:
