On Jul 12, 2012, at 9:11 PM, m...@freebsd.org wrote:
On Thu, Jul 12, 2012 at 4:43 PM, Justin Hibbits
<chmeeed...@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
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.
- Justin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
