>Number:         11875
>Category:       kern
>Synopsis:       locking error in uvm_pager_put() or vnode pager
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 02 20:11:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Jason R Thorpe
>Release:        Jan 2, 2000 NetBSD-current + i386 MP
>Organization:
6th and Hugo Software
>Environment:
	
System: NetBSD swinger.shagadelic.org 1.5Q NetBSD 1.5Q (SWINGER.MP) #23: Tue Jan  2 17:29:48 PST 2001     thorpej@swinger.shagadelic.org:/u1/netbsd/sommerfeld_i386mp_1/syssrc/sys/arch/i386/compile/SWINGER.MP i386
Architecture: i386
Machine: i386
>Description:
	Upon an NFS server crash/reboot (the server is running an
	early UBC kernel with known bugs, and needs to be updated),
	a client (a dual-CPU x86 system running an MP kernel, doing
	a "make build" to test some pmap changes) ended up in the
	debugger:

simple_lock: locking against myself
lock: 0xcb30550c, currently at: ../../../../uvm/uvm_vnode.c:615
on cpu 0
last locked: ../../../../uvm/uvm_pager.c:536
last unlocked: ../../../../uvm/uvm_pager.c:873

	A "continue" at the db{0}> prompt seemed to recover
	everything (at least well enough for me to restart the
	build I was doing).

	The shell where the build was happening showed this:

mv: .depend: set times: Stale NFS file handle
mv: .depend: set owner/group: Stale NFS file handle
mv: .depend: set mode: Stale NFS file handle

	Given the nature of the failure (corresponding to an NFS
	server crash), I'm inclined to believe that the failure was
	not related to the TLB shootdown optimizations I am testing,
	but is rather an error recovery problem in the pager.

>How-To-Repeat:
	I'm not really sure how to repeat it, other than to cause your
	NFS server to go down at the "right" time during a build.

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: