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

[Max Khon]

Marius,

On Tue, Nov 30, 2010 at 1:24 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
>

Ok, this sounds reasonable. I changed it to be just  (VM_MAX_KERNEL_ADDRESS
- VM_MIN_KERNEL_ADDRESS)

> 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.
>

I thought about fixing memguard_fudge() too, but defining VM_KMEM_SIZE_MAX
seemed to be less intrusive change to me.

Max