Thanks so much! It turns out that the box was actually
being hammered
DoS style from a remote user who let a script go wild.
It's good to know that 3.0 dynamically maps these entries.
It looks
like it is time to schedule an upgrade.
You wouldn't happen to have any pointers as to where I could
learn more
about MAX_KMAPENT and kmem map, etc, etc, would you?
Thanks again,
Michael
Joseph A. Dacuma wrote:
>> I have a NetBSD 2.0.1 box that died last night with
the following error
>> on the console:
>>
>> panic: uvm_mapent_alloc: out of static map entries,
check MAX_KMAPENT
>> (currently 1114)
>> Stoppped in pid 15.1 (pagedaemon) at
netbsd:cpu_Debugger+0x4
>>
>> Of course, things are fine after a reboot.
>>
>> Trying to be the good scientist, I need to get a
better understanding of
>> what 'MAX_KMAPENT' is and what 'uvm_mapent_alloc'
is. If anyone can
>> help, I'd really appreciate it.
>>
>> I have to assume that there is some sort of
resource issue going on
>> here, and I don't want to just reboot the box and
forget about it.
>>
>> Thanks so much,
>>
>> Michael
>>
>>
>
> Hi Mr. Gorsuch!
>
> You seem to have a very busy server. MAX_KMAPENT from
what I understand is
> the number of static entries in kmem map (kernel
virtual memory). Things
> are fine after reboot since your kernel memory map has
been refreshed.
>
> I had a similar problem before. What I did was fiddle
between maxusers,
> max kmapent, nkmempages. It helped me when I was still
using 2.x but now
> its different with my 3.x boxes as the in-kernel map
entries are now
> dynamically allocated. This was months ago so I really
couldn't remember
> in detail the magic numbers that worked for me.
>
> HTH,
>
> Joseph
>
>
>
|