panic with DEBUG_MEMGUARD on PowerPC

[Justin Hibbits]

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

- Justin