Re: panic with DEBUG_MEMGUARD on PowerPC

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

I'll see about crafting a patch when I can get access to a machine
that works (my current woes with my laptop, VM image, etc. are quite
frustrating).  The gist is that, in the absence of a kmem_max, the
routine for determining the size of the kmem map should use the
kernel_map's size as a limiting factor.  In this case it looks like
the map's size is 512MB.

Cheers,
matthew