Re: panic with DEBUG_MEMGUARD on PowerPC

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:
>
> panic: kmem_suballoc: bad status return of 3
> cpuid = 0
> KDB: stack backtrace:
> 0xd0004ad0: at kdb_backtrace+0x4c
> 0xd0004b40: at panic+0x224
> 0xd0004ba0: at kmem_suballoc+0x8c
> 0xd0004bd0: at kmeminit+0x1ac
> 0xd0004c20: at mi_startup+0x13c
> 0xd0004c50: at btext+0xc0
>
> 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.

Thanks,
matthew