Date: Wed, 17 Nov 1999 23:59:46 -0800 (PST) From: Matthew Dillon <dillon@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 Message-ID: <199911180759.XAA78788@apollo.backplane.com> References: <199911161847.NAA07576@cs.rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
:> :
:>
:> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911180759.XAA78788>