svn commit: r216016 - head/sys/sparc64/include

[Marius Strobl]

On Tue, Nov 30, 2010 at 12:31:31AM +0600, Max Khon wrote:
> Marius,
> 
> On Mon, Nov 29, 2010 at 1:45 AM, Marius Strobl <marius at alchemy.franken.de>wrote:
> 
> On Sun, Nov 28, 2010 at 07:26:20PM +0000, Max Khon wrote:
> > > Author: fjoe
> > > Date: Sun Nov 28 19:26:20 2010
> > > New Revision: 216016
> > > URL: http://svn.freebsd.org/changeset/base/216016
> > >
> > > Log:
> > >   Define VM_KMEM_SIZE_MAX on sparc64. Otherwise kernel built with
> > >   DEBUG_MEMGUARD panics early in kmeminit() with the message
> > >   "kmem_suballoc: bad status return of 1" because of zero "size" argument
> > >   passed to kmem_suballoc() due to "vm_kmem_size_max" being zero.
> > >
> > >   The problem also exists on ia64.
> > >
> > > Modified:
> > >   head/sys/sparc64/include/vmparam.h
> > >
> > > Modified: head/sys/sparc64/include/vmparam.h
> > >
> > ==============================================================================
> > > --- head/sys/sparc64/include/vmparam.h        Sun Nov 28 18:59:52 2010
> >      (r216015)
> > > +++ head/sys/sparc64/include/vmparam.h        Sun Nov 28 19:26:20 2010
> >      (r216016)
> > > @@ -237,6 +237,14 @@
> > >  #endif
> > >
> > >  /*
> > > + * Ceiling on amount of kmem_map kva space.
> > > + */
> > > +#ifndef VM_KMEM_SIZE_MAX
> > > +#define      VM_KMEM_SIZE_MAX        ((VM_MAX_KERNEL_ADDRESS - \
> > > +    VM_MIN_KERNEL_ADDRESS + 1) * 3 / 5)
> > > +#endif
> > > +
> > > +/*
> > >   * Initial pagein size of beginning of executable file.
> > >   */
> > >  #ifndef      VM_INITIAL_PAGEIN
> >
> > How was that value determined?
> >
> 
> I've just copied it from amd64 to be non-zero for now. Do you have a better
> idea of what it should look like?
> 

Well, on sparc64 VM_MAX_KERNEL_ADDRESS already is dynamically adjusted
to the maximum appropriate for the specific CPU during the early cycles
of the kernel so I'd think one could just use VM_MAX_KERNEL_ADDRESS -
VM_MIN_KERNEL_ADDRESS for VM_KMEM_SIZE_MAX there, I'm not sure what
the intention of the ceiling provided by that macro actually is though
In any case, the commit message of r180210 which changed the amd64
version to the current one talks about limiting the kmem map to 3.6GB
and while it also fails to explain where that value comes from it
looks rather amd64 specific and the formula used by the macro will
result in a different ceiling on sparc64 and thus inappropriate. I've
CC'ed alc@ who hopefully can shed some light on this.
Apart from this the actual bug here seems to be that memguard_fudge()
can't deal with a km_max being zero or that zero is passed to it as
kmeminit() allows for VM_KMEM_SIZE_MAX not being defined.

Marius