Subject: Re: Problems with KA650 and -current
To: None <port-vax@netbsd.org>
From: Tom Ivar Helbekkmo <tih@nhh.no>
List: port-vax
Date: 12/10/1998 20:55:10
I wrote:

> My 1.3F kernel displays:
>
> MicroVAX 3500/3600
> realmem = 16736256
> avail mem = 12033024
> Using 817 buffers containing 836608 bytes of memory.
> 
> And the 1.3I (both my locally built one, and the one from the snapshot):
> 
> MicroVAX 3500/3600
> realmem = 16736256
> avail mem = 13955072
> Using 25 buffers containing 102400 bytes of memory.
>
> Note that buffer usage!

This is really, really weird.  I've been reading a bit more of the
code, and I'm getting convinced that either I'm totally confused, or
there is a bit of mix-up in there between the various sizes and shifts
that are used.  It doesn't help that somehow, in NetBSD terminology,
clicks and pages have been "redefined" so that in NetBSD/vax-current,
a page is 512 bytes (NBPG, with a corresponding PGSHIFT of 9), while
the click is 4096 bytes (CLBYTES, with a CLSHIFT of 12).  Throw in a
CLSIZE of 8, with a CLSIZELOG2 of 3, reflecting the old idea that the
click is the smallest address shift the memory management hardware can
relate to, and things get really confusing.

Still, the printf() that outputs the above 102400 _does_ multiply the
internal bufpages count by CLBYTES, which seems reasonable.  The error
occured a bit earlier, when the bufpages value was calculated based on
physmem (also in 4096 byte "clicks") -- but then, down on line 391 or
thereabouts of machdep.c, it's divided by CLSIZE!  This seems to be a
misunderstanding carried over from other ports, where CLSIZE is 1
(because what we used to call a click is 1), and it doesn't matter.
With a CLSIZE of 8, we get 1/8 the buffer space we intended.  This
also affects swap buffer header allocation, of course.

Now, this has me a bit worried.  Sure, this might be the only place
this error is found, but if similar erroneous uses of CLSIZE (or the
failure to take it into account) are found elsewhere in the code (and
it doesn't have to be below /sys/arch/vax, either), there might be
interesting trouble.  A quick grep shows that the VAX is the only of
the NetBSD ports that has a CLSIZE that isn't 1.

I'm going to test a kernel built without the erroneous "/ CLSIZE" bits
in it tonight, and report back later.

-tih
-- 
Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"