>Number:         13352
>Category:       kern
>Synopsis:       NEW_PIPE causes occasional panic: lockmgr: release of unlocked lock!
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jul 01 09:17:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Greg A. Woods
>Release:        2001/06/19
>Organization:
Planix, Inc.; Toronto, Ontario; Canada
>Environment:

System: NetBSD proven 1.5W NetBSD 1.5W (PROVEN) #2: Tue Jun 19 21:48:56 EDT 2001 woods@proven:/work/woods/NetBSD-src/sys/arch/i386/compile/PROVEN i386
Architecture: i386
Machine: i386

>Description:

	Twice now since Jun 20 I've awoken to find my development server
	stuck here:

	panic: lockmgr: release of unlocked lock!
	Stopped in pid 4517 (cron) at   cpu_Debugger+0x4:       leave
	db> trace 
	cpu_Debugger(d0ba48d8,6,0,d0d5ce04,c019c8ce) at cpu_Debugger+0x4
	panic(c0384380,8085000,1,3000,d0a12420) at panic+0x8e
	lockmgr(d0ba48d8,6,0) at lockmgr+0x88e
	uvm_loan(d0ba48d4,8085000,3000,c0cf7890,2) at uvm_loan+0x243
	pipe_write(d0ddc734,d0ddc750,d0d5cf04,c08a3f00,1) at pipe_write+0x38a
	dofilewrite(d0e5e91c,5,d0ddc734,8084000,32fb) at dofilewrite+0x94
	sys_write(d0e5e91c,d0d5cf80,d0d5cf78) at sys_write+0x63
	syscall_plain(2b,805002b,bfbf001f,807001f,8084000) at syscall_plain+0x98
	db> 

	Apparently /etc/daily was still running.  Next time I'll try to
	be smart enough to remember to do "ps" too, just to be sure what
	was running.

	Other "heavy" use of pipe (eg. mpg123|sox|auplay with a 44k
	stereo stream, simultaneous with 'COPTS=-pipe make build', plus
	other minor stuff) has not caused any problem.

	One thing that may or may not be of interest is that the mpg123
	player occasionally loses something and gets into a state where
	all I hear is static.  It's not the MP3 side as mpg123 shows
	that it's still successfully receiving and decoding the stream
	at about the same rate as always.  This seems to happen whenever
	there's heavy NFS client activity (i.e. to another NFS server).
	I thought this might have been just general network clogging in
	the path between auplay and my Xterm, but I've since done large
	FTPs from the same server over the same network path to another
	machine plugged into the hub right beside the xterm and there
	wasn't even a peep or pause in the audio.  (The ftp ran at about
	400kb/s, which I think is the max speed of the disk on the
	client I was pulling files down to.)  So, I've yet to find the
	cause of this breakage -- my fear is maybe there's a point where
	the pipe from mpg123 to sox (or even sox to auplay) might be
	dropping a "packet" and getting things out of sync....

	So far though the code built with 'cc -pipe' seems A-OK....

	Unfortunately at this time I cannot collect a coredump (see PR#13288)

	Note I'll be rebooting with a 2001/06/24 kernel today....

>How-To-Repeat:

	unknown

>Fix:

	unknown

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