Date: Thu, 12 Jul 2012 18:11:16 -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-5Xix46MaYAwBek6hWvcOHZ7%2BR_4cpdG5SH_5RD7difQ@mail.gmail.com> In-Reply-To: <A3CD63CD-694A-48F5-B0F7-9C8923AFCB90@gmail.com> References: <A3CD63CD-694A-48F5-B0F7-9C8923AFCB90@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: > > 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@ fixed that in r216425. Thanks, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMBSHm-5Xix46MaYAwBek6hWvcOHZ7%2BR_4cpdG5SH_5RD7difQ>