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