I forgot some information, apparently...  Here are answers to some
of the question/suggestions raised.

>  o What is the stack backtrace from the panic/crash?  That could
>    be valuable to know when diagnosing this.

Not sure.  I am not all that good with the kernel debugger.  I'll
try to figure out how to get this...

>  o Which version of NetBSD are we talking about (if we're talking
>    some version of -current, the source date could be useful to
>    know)?

1.3.2

>  o Are you using UVM?

Not on purpose.  If it is on by default, I am using it.  Otherwise,
I am not.

> My initial guess is that you could be running out of some kernel
> resource used for the buffer management of the TCP sessions (?).

I have plenty of mbufs, see below.

> Are all the processes "active" in pushing out data, or are they
> low-bandwidth connections, not likely to consume a significant
> amount of their buffer needs?

Each process starts, sets up a TCP connection, transmits some amount
of data as quickly as possible, closes the connection and then
exits.

> You probably need an increase in NMBCLUSTERS. Compiler a kernel with
> 
> options		NMBCLUSTERS=2048
> 
> and try it again.

Sorry, I should have noted that I have done that...  From my kernel
config file...

options         NMBCLUSTERS=4096
options         NKMEMCLUSTERS="(18 * 1024 * 1024/CLBYTES)"

This provides plenty of mbufs for ~200 connections (each with a 16
KB socket buffer).  I have run up against the mbuf limit before and
I get an mb_map_full (or something like that) error message (not
panic).  I was pretty careful about making sure that I had enough
mbufs, so I don't think that is the problem.
 
>    try increasing MAX_KMAPENT (defined in vm/vm_map.h) a bit.  i
> suspect you are running out of kernel map entries.

This is one I have not tried...  I'll give it a shot.

Thanks for all the help!  We appreciate it!

allman


---
http://gigahertz.lerc.nasa.gov/~mallman/