From owner-freebsd-stable Fri Oct 3 00:15:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA26112 for stable-outgoing; Fri, 3 Oct 1997 00:15:56 -0700 (PDT) Received: from dog.farm.org (gw-serial2.farm.org [207.111.140.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA26107 for ; Fri, 3 Oct 1997 00:15:51 -0700 (PDT) Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id AAA05220; Fri, 3 Oct 1997 00:17:57 -0700 (PDT) Date: Fri, 3 Oct 1997 00:17:57 -0700 (PDT) From: Dmitry Kohmanyuk Message-Id: <199710030717.AAA05220@dog.farm.org> To: ccaputo@alt.net (Chris Caputo) Cc: freebsd-stable@freebsd.org Subject: Re: Another NFS bogon in 2.2-stable? Newsgroups: cs-monolit.gated.lists.freebsd.stable Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-freebsd-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article you wrote: > We are definitely seeing problems with nfsv2 and either tcp or udp > connections. We have tried the -r=1024 fix for udp and that didn't help. > We use the 2.2-stable box as an NFS client to a NetApp NFS server. After > a little while, the FreeBSD box gets into a state where any command that > causes NFS activity hangs, including a simple "df". Once in this state, > the command can not be killed, even with "kill -9" from root. Which version of Data ONTAP (NetApp OS) are you running?? I have 4.1d talking to 2.2-stable clients and have never had this problem with nfsv2 (with nfsv3, you get problems, like you cannot build the kernel on NFS /usr/src/sys because vnode_if.c is built with 4K block of zero bytes. (If you remove this file, and type make again, it works.) I have default mount options, and use NetApp for /usr/cvs , /home , and other actively-used filesystems. > I am gonna start comparing the 2.2-stable sources with 3.0-current sources > to see if there are any obvious fixes. If anyone has any other ideas, > please let me know. We have an immediate desire to get beyond this. ;-) -- old unix hackers don't die, they just turn into zombie processes -- net.someone