Date: Mon, 21 Feb 2005 12:00:56 +0000 From: Peter Risdon <peter@circlesquared.com> To: Mike Jeays <Mike.Jeays@rogers.com> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: NFS hangs on 5.3-RELEASE-p5 Message-ID: <1108987256.96957.191.camel@lorna.circlesquared.com> In-Reply-To: <1108693694.708.14.camel@chaucer.jeays.ca> References: <Pine.NEB.3.96L.1050217120755.38170E-100000@fledge.watson.org> <1108693694.708.14.camel@chaucer.jeays.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2005-02-17 at 21:28 -0500, Mike Jeays wrote: > On Thu, 2005-02-17 at 07:09, Robert Watson wrote: > > On Thu, 17 Feb 2005, Peter Risdon wrote: > > > > > On Tue, 2005-02-15 at 14:23 +0200, Simonas Kareiva wrote: > > > > > > [...] > > > > > > > > The problem is, that the nfs server hangs after running for a while, > > > > like, 20 minutes. Any file operations (at the nfs mount points and > > > > below) hang on the ftp server too, making it inaccessible. > > > > > > I'm having the same problem here, also with 5.3 but in my case with > > > rsync. Oddly, the hang often happens at exactly the same point in a file > > > hierarchy and I initially suspected a problem with some specific files, > > > then with certain file types (it always seemed to hang when copying > > > pdfs). But it now seems to be more general than that. In fact, even > > > periods of inactivity can cause the nfs mount on the client to time out. > > > > If you do a "ps axl | grep nfsd", what wait channel is shown for the nfsd > > that's wedged? If you compile your kernel with "options DDB", "options > > KDB", and "options BREAK_TO_DEBUGGER", wait for the problem to occur, > > break into the debugger using ctrl-alt-escape or a serial break on serial > > console, "trace pid" the process, and type "continue" to get out of the > > debugger, could you send me the output of the stack trace for the nfsd > > process? > > > > Robert N M Watson > Try the following incantation in /etc/fstab. > faraday:/usr /faraday nfs rw,-r=1024,noauto 0 0 > > There is a reference in the Handbook, section 23.3.5 > For me, this completely cured a similar problem. Yes, so gathering that this is a problem of some network cards, I swapped out the cards on the problematic client and the problem disappeared. I can't understand why I didn't pick up on this section in the handbook before. Thanks for your help and apologies for wasting bandwidth. Peter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1108987256.96957.191.camel>