> 
> Hi all,
> 
> I've finally gotten around to updating one of my systems to -current (my 
> last kernel build on this machine was 1.2A, from early November 1996).
> The machine is a Sparc-20 with 128MB of main memory. I've built essentially
> a GENERIC kernel with all the non-sun4m stuff snipped out. When I try to
> build it, I get:
> 
> 	panic: cluster_rbuild: too much memory
> 
> just after /etc/rc begins to start the network (i.e. it is past init, and
> in the middle of going multi-user).

Maybe the change of thorpej to sys/arch/sparc/sparc/machdep.c (Dec 22, 1996):

  +       /*
  +        * XXX stopgap measure to prevent wasting too much KVM on
  +        * the sparsely filled buffer cache. 
  +        */
  +       if (nbuf > 128)
  +               nbuf = 128;

If I understand the buffer management, the difference is as follows:

Before this change I had nbuf == bufpages (407 in my case).
Now I have nbuf == 128 and bufpages == 407.

In kern/vfs_bio.c, function bufinit(), nbuf buffers get allocated.
I get 23 (bufpages % nbuf) buffers of 4 (bufpages / nbuf + 1) times CLBYTES
and 105 (rest) buffers of 3 (bufpages / nbuf) times CLBYTES.

As buffer data may be merged to get bigger buffers it is always possible to
get a buffer of 3+3+3+3+3 == 15 times CLBYTES.

kern/vfs_cluster.c, function cluster_rbuild() contains the following code:

(line 349)	if (tbp->b_bufsize + size > MAXBSIZE) {
	#ifdef DIAGNOSTIC
			if (tbp->b_bufsize != MAXBSIZE)
				panic("cluster_rbuild: too much memory");

Taking the buffer from above this evaluates to:

		if (15*4k + 8k > 64k)		YES!!
			if (15*4k != 64k)	YES!!
				panic ....

My -current kernel (sun4c, Sparc2, Weitek) runs fine since I removed this
'nbuf = 128' line.

-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (W Germany)