From owner-freebsd-hackers  Wed Nov 17 23:59:49 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 062AB151C4
	for <freebsd-hackers@FreeBSD.ORG>; Wed, 17 Nov 1999 23:59:47 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id XAA78788;
	Wed, 17 Nov 1999 23:59:46 -0800 (PST)
	(envelope-from dillon)
Date: Wed, 17 Nov 1999 23:59:46 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199911180759.XAA78788@apollo.backplane.com>
To: "David E. Cross" <crossd@cs.rpi.edu>
Cc: Doug White <dwhite@resnet.uoregon.edu>,
	"David E. Cross" <crossd@cs.rpi.edu>, freebsd-hackers@FreeBSD.ORG,
	crossd@cs.rpi.edu
Subject: Re: vmpfw in pine via NFS 
References:  <199911161847.NAA07576@cs.rpi.edu>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:> :
:> 
:>     Which FreeBSD release is being used here?  What kind of NFS mount is 
:>     being used (localhost mount?) 
:
:Ok, I have some additional details, as I was able to mostly resolve the issue.
:
:Yes, mail is nfs exported, but that does not appear to be the issue in this
:case.  pine is run from nfs mounted "/usr/local" pine would hang every time
:a user would go to send a composed message and wind up in "vmpfw".  The "fix"
:was to go to the NFS server for /usr/local and do "mv pine pine.old; cp 
:pine.old pine".  This would (obviously) not affect any of the old pine's, it
:would however allow any new pines to run w/o problems.  Note that any access
:to /usr/local/bin/pine.old on the client machine would result in a hang.
:Specifically "file /usr/local/bin/pine.old" resulted in "vmpfw" as did "cmp"
:and a couple of others.  All of these worked just fine on the NFS server.
:The release in question is 3.3-STABLE from this past Friday (Nov. 12).
:
:--
:David Cross                               | email: crossd@cs.rpi.edu 

    pine does some really *bad* things with mmap(), as I recall.  I'm trying
    to remember what the bug was.  

    The thing to do is to run a debug kernel, and when you hit the problem
    do a 'ps axl' and locate all the processes that are 'stuck' in a state
    that they shouldn't be stuck in.  It's almost certainly a deadlock 
    somewhere.  There should be more then one.  Once you have identified
    the processes you can gdb the running kernel and get a backtrace of
    each stuck process:

	gdb -k kernel.debug /dev/mem
	proc XXX
	back
	proc YYY
	back
	...

    I think the problem is related to pine's use of MAP_PRIVATE mmap's of
    mail files, and then going through and modifying every page as it
    scans the map.  This causes a large number of write faults to occur and
    even though the copy-on-write's are creating private pages, vm_fault
    still winds up locking the underlying file.  This can cause a deadlock
    to occur somewhere - I'm not exactly sure where. 

    I recall that there are some VM-related situations where NFS can get
    into a deadlock due to side effects, but I don't recall it well enough
    to figure it out without some backtraces to work with.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



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