Re: panic with DEBUG_MEMGUARD on PowerPC

On Sun, 15 Jul 2012 09:39:03 -0700
mdf_at_FreeBSD.org wrote:

> On Sat, Jul 14, 2012 at 8:39 AM, Justin Hibbits
> <chmeeedalf_at_gmail.com> wrote:
> > On Jul 13, 2012, at 12:20 AM, mdf_at_freebsd.org wrote:
> >
> >> On Thu, Jul 12, 2012 at 6:33 PM, Justin Hibbits
> >> <chmeeedalf_at_gmail.com> wrote:
> >>>
> >>> On Jul 12, 2012, at 9:11 PM, mdf_at_freebsd.org wrote:
> >>>
> >>>> On Thu, Jul 12, 2012 at 4:43 PM, Justin Hibbits
> >>>> <chmeeedalf_at_gmail.com> wrote:
> >>>>>
> >>>>>
> >>>>> When tracking down a panic exposed by INVARIANTS, I tried
> >>>>> setting DEBUG_MEMGUARD, so I could find the culprit that's
> >>>>> trashing freed memory.
> >>>>> However, this causes a panic at bootup.  It shows up right
> >>>>> after the first
> >>>>> WARNING: WITNESS message, with the following:
> >>>>>
> >>>>> Tracing, and printf() debugging, I see arguments to
> >>>>> vm_map_findspace(): start: 0xD0000000, length: 4246446080, and
> >>>>> map->max_offset = 4026531839.
> >>>>>
> >>>>> Beyond that, I'm lost with tracking this down.  Machine is a
> >>>>> dual processor
> >>>>> PowerPC G4, with 2GB RAM.
> >>>>
> >>>>
> >>>>
> >>>> The length is 0xFD1BA000 which is almost 4GB.  Asking for 4GB of
> >>>> virtual space for 2GB of RAM sounds about right (it's been a
> >>>> while since I was in this code), unless this is a 32-bit kernel,
> >>>> in which case it'd be too much since there isn't that much
> >>>> virtual space available.
> >>>>
> >>>> So, is the kernel 32-bit?  What are the values used and returned
> >>>> by memguard_fudge()?  The intent of that routine is to get
> >>>> kmeminit() to allocate a larger map so memguard can use part of
> >>>> it for private virtual addresses.  But it shouldn't be asking
> >>>> for "too much"; i.e. the intent was to check both physical and
> >>>> virtual space available and be greedy, but not too greedy.
> >>>>
> >>>> There were some issues with that code for some platforms that
> >>>> e.g. didn't define a VM_KMEM_SIZE_MAX, but alc_at_ fixed that in
> >>>> r216425.
> >>>
> >>>
> >>> It is a 32-bit kernel, on 32-bit hardware.  The values for
> >>> memguard_fudge are (defaults):
> >>>
> >>> tmp: 4246446080, vm_kmem_size: 117440512, vm_kmem_size_max: 0
> >>>
> >>> When setting vm.kmem_size/vm.kmem_size_max to 2GB they are:
> >>>
> >>> tmp: 2147483648, vm_kmem_size: 214793648, vm_kmem_sizee_max:
> >>> 2147483648 (all
> >>> 2GB).
> >>>
> >>> But the start and map->max_offset remain the same on all runs I
> >>> make.
> >>
> >>
> >> memguard_fudge is still broken for 32-bit architectures with no
> >> vm_kmem_max.  In the absence of a km_max to limit the value, we
> >> essentially use twice the physical memory for the virtual limit.
> >> But with 2GB on a 32-bit machine, this requires 4GB of virtual
> >> space.
> >>
> >> Setting vm_kmem_size_max to 2GB should work; I'd expect to see
> >> tmp=about 200MB, which is much larger than the input 112MB but the
> >> allocation should work.  But I don't really know what else PowerPC
> >> has need of for virtual space, so that still could be too large.
> >>
> >> You can try smaller values of vm_kmem_size_max, like 1GB or 512MB.
> >> You shouldn't need to set vm_kmem_size at all.  At some point the
> >> added space for the memguard_map will be small enough that the
> >> kmem_suballoc will work.
> >>
> >> Hmm, what is the min_offset and max_offset of kernel_map when the
> >> call to memguard_fudge is made?
> >>
> >> Thanks,
> >> matthew
> >
> >
> >
> > Without setting vm.kmem_size/vm.kmem_size_max, I see the following:
> >
> > map: 0x1000000, min_offset: 0xD0000000, max_offset: 0xEFFFFFFF
> >
> > It does boot when I set vm.kmem_size=256M/vm.kmem_size_max=512M.
> >
> > When I tried 512M/1024M, it panicked at the same place --
> > kmem_suballoc from kmeminit.  So it looks like I have to set
> > vm.kmem_size/vm.kmem_size_max way back in order for it to boot with
> > memguard(9).
> 
> Please try the attached patch (or at
> http://people.freebsd.org/~mdf/memguard.diff).
> 
> Thanks,
> matthew

Hi Matthew,

That patched works perfectly.

Thanks,
Justin