Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Jul 2012 21:20:54 -0700
From:      mdf@FreeBSD.org
To:        Justin Hibbits <chmeeedalf@gmail.com>
Cc:        freebsd-current <freebsd-current@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject:   Re: panic with DEBUG_MEMGUARD on PowerPC
Message-ID:  <CAMBSHm-CM0hc2Cu=C-zf7ArENqVz9iOHCjb0wMSPCnYQbXKqdA@mail.gmail.com>
In-Reply-To: <307005B6-C8E5-4DCF-BD10-6BC79D8C2FE3@gmail.com>
References:  <A3CD63CD-694A-48F5-B0F7-9C8923AFCB90@gmail.com> <CAMBSHm-5Xix46MaYAwBek6hWvcOHZ7%2BR_4cpdG5SH_5RD7difQ@mail.gmail.com> <307005B6-C8E5-4DCF-BD10-6BC79D8C2FE3@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 12, 2012 at 6:33 PM, Justin Hibbits <chmeeedalf@gmail.com> wrote:
> On Jul 12, 2012, at 9:11 PM, mdf@freebsd.org wrote:
>
>> On Thu, Jul 12, 2012 at 4:43 PM, Justin Hibbits <chmeeedalf@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@ 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMBSHm-CM0hc2Cu=C-zf7ArENqVz9iOHCjb0wMSPCnYQbXKqdA>