On Jul 13, 2012, at 12:20 AM, m...@freebsd.org wrote:
On Thu, Jul 12, 2012 at 6:33 PM, Justin Hibbits
<chmeeed...@gmail.com> wrote:
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:
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
_______________________________________________
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"
