[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:
>