kernel/1893: panic: malloc: out of space in kmem_map (fwd)

[openbsd@slate.irt.drexel.edu]

>Number:         1893
>Category:       kernel
>Synopsis:       panic: malloc: out of space in kmem_map
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bugs
>State:          open
>Class:          support
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 21 09:40:02 MDT 2001
>Last-Modified:
>Originator:     Andrew Brennan
>Organization:
Drexel University
>Release:        OpenBSD gomez 2.9 GENERIC#653 i386
>Environment:
	System      : OpenBSD 2.9
	Architecture: OpenBSD.i386
	Machine     : i386
>Description:

panic: malloc: out of space in kmem_map
Stopped at      _Debugger+0x4:  leave
Run at least 'trace' and 'ps' and include the output when reporting this panic.

ddb> trace
_Debugger(56,56000,0,0,56,e14f8000,f9df9e48,e01858ee,e0185500,e0481fd4,56000,0,
f9d3b4d8,55004,e2468000,0,f9d3b4d8,ffffffff,56000,0,0,e053aec0,20,0,13,e052a1a8
,f9df9ea8,e02782cf,55004,62,0,e02782c0,55004,62,0,e01b589f,e1fb1a00,f9ddba5c,f9
d2fac0,e1fb6700,f9df9f88,8000,15400,e01ce16d,dff7f000,f9ddba5c,f9df9ee8,e027e4f
e,e22bf000,15401,f9df9ee8,e027e65b,f9ddba5c,1000,10000,f9dd2754,e1fb1a00,1000,f
9d2fac0,e1fc8300,1) at _Debugger+0x4
_panic(e0185500,e0481fd4,56000,0,f9d3b4d8) at _panic+0x81
_malloc(55004,62,0,e02782c0,55004) at _malloc+0x292
_amap_extend(f9ddba5c,1000,10000,f9dd2754) at _amap_extend+0x14f
_uvm_map(f9d2fac0,f9df9f34,1000,0,0,1b0717,8,e018c2c2) at _uvm_map+0x257
_sys_obreak(f9dd2754,f9df9f88,f9df9f80,e1756a00,0) at _sys_obreak+0x8b
_syscall() at _syscall+0x242
--- syscall (number 17) ---
0x401c8011:
ddb> ps
  PID   PPID   PGRP    UID  S       FLAGS  WAIT       COMMAND
 20344  21332  20344      0  3      0x4086  ttyin      csh
 21332   8033  21332   1000  3      0x4086  pause      csh
  8033  11388  11388      0  3        0x84  select     sshd
  5241      1   5241      0  3      0x4086  ttyin      getty
* 2503      1   2503      0  2         0x4             snort
 19071  15769  19071      0  3      0x4086  ttyin      csh
 15769  20911  15769   1000  3      0x4086  pause      csh
 20911  11388  11388      0  3        0x84  select     sshd
  5795      1   5795      0  3      0x4086  ttyin      getty
 19218      1  19218      0  3      0x4086  ttyin      getty
 13414      1  13414      0  3      0x4086  ttyin      getty
 18288      1  18288      0  3      0x4086  ttyin      getty
 32304      1  32304      0  3        0x84  nanosleep  cron
 11388      1  11388      0  3        0x84  select     sshd
 29213      1  29213      0  3     0x40184  pause      sendmail
 15579      1  15579      0  3       0x184  pause      inetd
 16092      1  16092      0  3        0x84  select     portmap
  4686      1   4686      0  2        0x84             syslogd
     5      0      0      0  3    0x100204  crypto_wa  crypto
     4      0      0      0  3    0x100204  syncer     update
     3      0      0      0  3    0x100204  reaper     reaper
     2      0      0      0  3    0x100204  daemon_sl  pagedaemon
     1      0      1      0  3      0x4084  wait       init
     0     -1      0      0  3     0x80204  scheduler  swapper
ddb> 

>How-To-Repeat:

   Reproducing the problem isn't difficult - but might be for sites that 
   aren't seeing the level of traffic that is passing here.  I start the
   Snort package, monitor the traffic to my external links and wait for
   a crash.  It usually goes down within a few hours.  Vague, but that's
   the best test I have at the present time.

>Fix:

   Limit my traffic through the segment?  Someone directed me to the bit
   in the options(4) page for allocating more memory using NKMEMCLUSTERS
   (I mistakenly looked at NMBCLUSTERS the first time, so I figured this
   was a different problem) and I'm going to try that next.  My kernel's
   a GENERIC one at this time, though.


>Audit-Trail:
>Unformatted: