Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Dec 2004 07:50:32 GMT
From:      "Rob Swindell" <rob@synchro.net>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: misc/75510: panic: kmem_malloc(4096): kmem_map too small
Message-ID:  <200412280750.iBS7oWVB013500@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR misc/75510; it has been noted by GNATS.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200412280750.iBS7oWVB013500>