Hal Murray <murray@pa.dec.com> writes:
> The GENERIC kernel has the same limit/bug, so after the install was 
> all finished I had a system that didn't work.

So, thinking about it some, this is really a bug, not just a limit.

Thinking about it, what's happening here is that at startup, the 'fxp'
driver is allocating a bunch (where it looks like 'a bunch' is 64) of
clusters for receive buffers.

Make that 4 fxp's, and you quickly hit the default value of
NMBCLUSTERS (256).


> What's the disadvantage of having NMBCLUSTERS too big?

On some ports, I don't think there's any other than you can eat more
network memory than you'd otherwise want to.

On the x86 (and many others), I think you eat memory for page tables.


> Could this be fixed with some auto-magic (boot time) adjustment based 
> on the memory size or number of network cards? 

I consider this at least partially a driver bug.  It's ... relatively
impolite for a driver to eat 25% of the available clusters, even if
there's only one of them.  Note that the fxp driver does this at
attach time, i.e. even if the interface is never ifconfig'd up!

At least if the allocations were done at 'ifconfig' time, you could be
a bit more sane about the failure cases, i think...



You should probably submit a PR on this problem.



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.