int/long confusion with maxbcache and maxswzone (fixes 6.0 on >12GB machines)

Kris Kennaway kris at
Wed Oct 12 09:55:39 PDT 2005

On Wed, Oct 12, 2005 at 12:36:50PM +0200, Max Laier wrote:

> > -int	maxswzone;			/* max swmeta KVA storage */
> > -int	maxbcache;			/* max buffer cache KVA storage */
> > +long	maxswzone;			/* max swmeta KVA storage */
> > +long	maxbcache;			/* max buffer cache KVA storage */
> >
> > However, des forgot to change the other definition of maxbcache in
> > <sys/buf.h>:
> >
> > extern int      maxbcache;              /* Max KVA for buffer cache */
> >
> > In fact, it's a good thing he didn't.  On sparc64 if you make that
> > variable a long it causes 32-bit integer overflows elsewhere, which
> > lead to severe filesystem damage on systems with >12GB RAM.  With the
> > above bug this is reduced to a hang at boot.
> Isn't it enough to introduce the maximum values below?  I imagine that the 
> ultimate goal is to get rid of the constrains, which will be easier if we 
> already have enough bits.

No, it's not.  As I mentioned, on 5.x you can work around this problem
by using the existing tunable to limit the parameter, but not on 6.0
unless you also revert long to int.  Something is getting confused
about whether that variable is a long or an int since it's
inconsistently defined.

Anyway, making these variables consistently long is a very bad idea
until more of the system is ready for that - that was the first thing
I tried when I identified the problem, and it completely destroyed all
of my filesystems within seconds, requiring a reinstall.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :

More information about the freebsd-sparc64 mailing list