Module Name: src
Committed By: riz
Date: Fri Sep 7 22:17:35 UTC 2012
Modified Files:
src/sys/uvm [netbsd-6]: uvm_km.c uvm_map.c
Log Message:
Pull up following revision(s) (requested by para in ticket #547):
sys/uvm/uvm_map.c: revision 1.320
sys/uvm/uvm_map.c: revision 1.321
sys/uvm/uvm_map.c: revision 1.322
sys/uvm/uvm_km.c: revision 1.130
sys/uvm/uvm_km.c: revision 1.131
sys/uvm/uvm_km.c: revision 1.132
sys/uvm/uvm_km.c: revision 1.133
sys/uvm/uvm_km.c: revision 1.134
sys/uvm/uvm_km.c: revision 1.135
sys/uvm/uvm_km.c: revision 1.129
Fix a bug where the kernel was never grown to accomodate the kmem VA space
since that happens before the kernel_map is set.
Don't try grow the entire kmem space but just do as needed in
uvm_km_kmem_alloc
Shut up gcc printf warning.
Cleanup comment. Change panic to KASSERTMSG.
Use kernel_map->misc_lock to make sure we don't call pmap_growkernel
concurrently and possibly mess up uvm_maxkaddr.
Switch to a spin lock (uvm_kentry_lock) which, fortunately, was
sitting there
unused.
Remove locking since it isn't needed. As soon as the 2nd
uvm_map_entry in kernel_map
is created, uvm_map_prepare will call pmap_growkernel and the
pmap_growkernel call in
uvm_km_mem_alloc will never be called again.
call pmap_growkernel once after the kmem_arena is created
to make the pmap cover it's address space
assert on the growth in uvm_km_kmem_alloc
for the 3rd uvm_map_entry uvm_map_prepare will grow the kernel,
but we might call into uvm_km_kmem_alloc through imports to
the kmem_meta_arena earlier
while here guard uvm_km_va_starved_p from kmem_arena not yet created
thanks for tracking this down to everyone involved
To generate a diff of this commit:
cvs rdiff -u -r1.120.2.2 -r1.120.2.3 src/sys/uvm/uvm_km.c
cvs rdiff -u -r1.313.2.3 -r1.313.2.4 src/sys/uvm/uvm_map.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
