m...@freebsd.org wrote:
On Tue, Dec 7, 2010 at 5:41 AM, Marius Strobl <mar...@alchemy.franken.de> wrote:
On Mon, Dec 06, 2010 at 02:30:01PM -0800, m...@freebsd.org wrote:
On Mon, Dec 6, 2010 at 2:07 PM, Marius Strobl <mar...@alchemy.franken.de> wrote:
[lots of snip]
With that one the kernel now survies memguard_init() but then panics
right afterwards when kmeminit() calls kmem_suballoc():
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
? ? ? ?The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #18 r215249:216120M: Mon Dec ?6 13:27:57 CET 2010
? ?mar...@v20z.zeist.de:/home/marius/co/build/head2/sparc64.sparc64/usr/home/m4
WARNING: WITNESS option enabled, expect reduced performance.
panic: kmem_suballoc: bad status return of 3
[more snip]
Shooting in the dark a little...
The bad status of 3 is presumably KERN_NO_SPACE because we attempted
to allocate too much space from the kernel_map. What are the actual
values of vm_kmem_size, kernel_map->min_offset, kernel_map->max_offset
at panic time?
vm_kmem_size=5610405888 min_offset=3221225472 max_offset=13958643712
This is on a US3i machine with 16GB RAM.
So kernel_map is from 0xC000_0000 to 0x3_4000_0000, or 0x2_8000_0000
bytes large. Double the vm_kmem_size is 0x2_9CD0_0000, which is why
this is failing.
This to me says that, for the moment, you need the
VM_MAX_KERNEL_ADDRESS define so that memguard does not take up too
much virtual space; at the moment this hardware is somewhat
constrained on virtual space.
Yes, I had thought that sparc64 had a much larger kernel address space.
Marius, I would suggest that you revert back to Max's original commit
that caps the kmem_map at 3/5 of the kernel address space. Right now,
you are allowing the kmem_map to consume the entire kernel address
space, and given the relatively modest size of the kernel address space,
a machine with more physical memory may try to create a kmem_map that
leaves no space for the buffer cache, pipes, thread stacks, etc.
Alan
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
