On Sat Feb 24 2007 at 13:11:36 -0500, Steven M. Bellovin wrote:
> I interrupted a 'find' via ^C; now, the 'find' command is wedged and
> is unkillable:
> 
> $ ps ltpts/8
>   UID   PID  PPID   CPU PRI NI VSZ  RSS WCHAN  STAT TTY       TIME COMMAND
> 54047  3651 26601   265  18  0 260 1024 pause  Ss   ttyp8  0:00.01 ksh 
> 54047 12588     1 12540  -2  0 624    4 vnlock DW   ttyp8- 0:01.48 find . -name
> 54047 22779  3651   265  28  0  72  660 -      R+   ttyp8  0:00.00 ps -ltpts/8 
> 
> $ uname -a; ls -l /netbsd
> NetBSD berkshire.machshav.com 4.99.9 NetBSD 4.99.9 (BERKSHIRE) #2: Tue Feb 20 22:47:45 EST 2007  smb@berkshire.machshav.com:/usr/BUILD/obj/sys/arch/i386/compile/BERKSHIRE i386
> -rwxr-xr-x  1 root  wheel  8018306 Feb 20 22:56 /netbsd
> 
> Does anyone need any data from this system?  Or should I just build a
> newer kernel and reboot?

I can't remember if anyone has addressed anything like this recently, but
at least the file system the find process was working with and a kernel
stacktrace for the find process would be helpful (t/t 0t12588 in ddb).
Output of "show vnode" in ddb for the vnode it's locking against (first
argument to VOP_LOCK) wouldn't hurt either.

-- 
Antti Kantee <pooka@iki.fi>                     Of course he runs NetBSD
http://www.iki.fi/pooka/                          http://www.NetBSD.org/
    "la qualité la plus indispensable du cuisinier est l'exactitude"