>Number:         14904
>Category:       port-powerpc
>Synopsis:       PowerPC w/o NEWPMAP deadlocks if faulting on kernel map when pv_nfree == 0
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-powerpc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Dec 10 11:50:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     dmissimer@rhapsodynetworks.com
>Release:        -current ca. 2001-7-17
>Organization:
Rhapsody Networks, Inc.
>Environment:
proprietary
>Description:
> %From: Chuck Silvers [chuq@chuq.com]
> %Sent: Saturday, December 08, 2001 10:58 PM
> %To: Duncan Missimer
> %Subject: Re: deadlock in PowerPC VM system

hi,

could you please enter this into the netbsd bug-tracking system
with the "send-pr" program?  this is fixed in NEWPMAP, but until
and unless that option becomes the default, this is still a problem.

thanks,
-Chuck


On Wed, Dec 05, 2001 at 06:54:14PM -0800, Duncan Missimer wrote:
> Anybody else seen this one?
> 
> 	sys__sysctl ->
> 	kern_sysctl ->
> 	sysctl_procargs ->
> 	uvm_io -> # creates kernel mapping
> 	uiomove ->
> 	kcopy ->
> 	bcopy ->
> 	trap ->
> 	uvm_fault ->  # acquires shared lock for kernel map
> 	pmap_enter ->
> 	pmap_enter_pv ->
> 	pmap_alloc_pv ->  # but pv_nfree is 0, so.....
> 	uvm_km_zalloc (== uvm_km_alloc1) ->
> 	uvm_map ->
> 	uvm_map_lock ->
> 	lockmgr(kernel_map, LK_EXCLUSIVE # hangs forever waiting for above
> shared lock to go away
> 
> 	Note that the WEHOLDIT test under LK_EXCLUSIVE doesn't help because
> it is
> 	impossible to identify the owner[s] of shared locks.
> 
> Got any good ideas? I understand that the kernel is based on current as of
> 7/17.
> 
> thanks,
> Duncan
>How-To-Repeat:
	Heavy load with lots of ps'es running
>Fix:
	Use NEWPMAP, apparently
>Release-Note:
>Audit-Trail:
>Unformatted: