Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Feb 2000 22:12:01 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        "David E. Cross" <crossd@cs.rpi.edu>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: stuck NFS procs
Message-ID:  <200002180612.WAA74819@apollo.backplane.com>
References:   <200002180016.TAA04080@cs.rpi.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
    I'd say this is more likely a VM bug rather then an NFS bug.  I don't
    think anything is being corrupted, I think it may just be a deadlock.

    For this sort of problem you should be able to gdb the kernel live on
    the system (without core'ing it) and then look at the stack backtrace
    for the processes in question.  You need a debug version of the kernel
    binary that is running.

    gdb -k kernel.debug /dev/mem
    proc  88194
    back
    proc 90317
    back

    Also do your ps axl again and make sure there aren't any other processes
    stuck in an odd state, looking at the code I don't see a possible deadlock
    between those two blocking states.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

:This is only the second time ever this has happened, but it is still an
:interesting problem... I have a large number of "emacs" processes stuck in 
:disk-wait.  Here is the ps axl  line for one such process:
:
:33639 88194     1   0 -22  0  5856  340 vmpfw  D     qi-   0:01.34 emacs proxy.
:
:Any attempt to access emacs on the client system would result in a type of
:hang for that process.  Here is a 'cat /usr/local/bin/emacs >/dev/null':
:
:2371 90317     1   3 -18  0   268    8 pgtblk D     p4-   0:00.02 cat /usr/loc
:
:To "fix" this I went to the NFS server and 'cp emacs emacs.new;rm emacs;mv emacs.new emacs'.  In essence forcing a new FH.  The old procs still stick arround.
:
:This leads me to believe the problem is entirely on the local system (ie,
:the kernel isn't asking for pages from the NFS server for that FH)
:
:Any ideas what could be corrupting the local cache (I am assuming that is the
:problem) like this.  Nothing of note in the dmesg.
:
:--
:David Cross                               | email: crossd@cs.rpi.edu 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002180612.WAA74819>