Date: Sat, 12 Feb 2000 13:31:04 +0000 From: David Malone <dwmalone@maths.tcd.ie> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: "David E. Cross" <crossd@cs.rpi.edu>, freebsd-hackers@FreeBSD.ORG Subject: Re: hard lock under 3.4-STABLE Message-ID: <20000212133104.A48171@walton.maths.tcd.ie> In-Reply-To: <200002120203.SAA85496@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Feb 11, 2000 at 06:03:16PM -0800 References: <200002120016.TAA82907@cs.rpi.edu> <200002120203.SAA85496@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 11, 2000 at 06:03:16PM -0800, Matthew Dillon wrote: > I presume its the client that is locking up? If you remove the > server binary and the client takes a page fault on the binary, > and does not have the page in the cache, what is supposed to happen > is that the program is supposed to seg fault when the NFS read fails. > It's quite possible that there is a bug in dealing with this situation > and if you can get it repeatable we can probably fix it fairly easily. I did some experiments with this sort of thing a few months ago. I think you can kill 3.X NFS client machines by truncating a binary on the NFS server. You can also make the machine extreamly slugish by catching SIGBUS and SIGSEGV in an executable and then causing one of these signals once the binary is modified. We see it quite frequently with people using MPI. I'll see if I can reproduce any of these effects and let you know how to do it. David. 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?20000212133104.A48171>