[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



The following reply was made to PR kernel/1893; it has been noted by GNATS.

From: Doug Clements <dsclements@linkline.com>
To: openbsd@slate.irt.drexel.edu
Cc: gnats@openbsd.org
Subject: Re: kernel/1893: panic: malloc: out of space in kmem_map (fwd)
Date: Fri, 22 Jun 2001 10:41:13 -0700

 Can you include a dmesg? I'd like to see if this may be related to the problems I'm having with fxp cards.
 
 --Doug
 
 On Thu, Jun 21, 2001 at 11:31:10AM -0400, openbsd@slate.irt.drexel.edu wrote:
 > 
 > >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:
 >