Date: Thu, 17 Dec 1998 08:00:00 -0800 (PST) From: David Malone <dwmalone@maths.tcd.ie> To: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/8732: nfs mounts with 'intr' can cause system hang Message-ID: <199812171600.IAA25007@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/8732; it has been noted by GNATS. From: David Malone <dwmalone@maths.tcd.ie> To: freebsd-gnats-submit@freebsd.org Cc: danderse@cs.utah.edu, nops@maths.tcd.ie Subject: Re: kern/8732: nfs mounts with 'intr' can cause system hang Date: Thu, 17 Dec 1998 15:49:22 +0000 I've having terrible problems with NFS - I get an uptime of about 3 days with NFS 3 and an uptime of about 3 hours with NFS 2 on our 3.0 machines. I think one of the problems I've been seeing mathces this PR exactly - the machine hangs and when I break to the debugger it seems to be deadlocked in vinvalbuf. The PR suggests that if tsleep returns an error this should returned. This would seem to be a sensible thing to do, as it is done just below with the return value of another tsleep. The PR also suggests that this may break some clients which don't check the return value of close, but I think they'll be broken anyway (NFS returns things like disk full on close I think). We have "tested" this suggestion once by jumping out of vinvalbuf from the debugger - the machine survived fine for several days afterwards. The other possibility suggested in this PR is not to allow the tsleep to be interupted, which would be far better than having the machine hang every few days! Is there any possibility of of someone commiting either of the fixes? I have three 3.0 machines here which I can do testing on if someone would like to suggest which is the correct fix. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812171600.IAA25007>