From owner-freebsd-current@FreeBSD.ORG Thu Oct 29 14:10:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B40B106568F; Thu, 29 Oct 2009 14:10:48 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from rustug.science.ru.nl (rustug.science.ru.nl [131.174.16.158]) by mx1.freebsd.org (Postfix) with ESMTP id C83F88FC19; Thu, 29 Oct 2009 14:10:47 +0000 (UTC) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by rustug.science.ru.nl (8.13.7/5.30) with ESMTP id n9TDqgHV005036; Thu, 29 Oct 2009 14:52:42 +0100 (MET) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.30) with ESMTP id n9TDqddE018549; Thu, 29 Oct 2009 14:52:39 +0100 (MET) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id 74A192E059; Thu, 29 Oct 2009 14:52:39 +0100 (CET) Date: Thu, 29 Oct 2009 14:52:39 +0100 From: Olaf Seibert To: Rick Macklem Message-ID: <20091029135239.GX841@twoquid.cs.ru.nl> References: <20091027164159.GU841@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -1.799 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 X-Mailman-Approved-At: Thu, 29 Oct 2009 20:01:45 +0000 Cc: freebsd-stable@freebsd.org, dfr@freebsd.org, freebsd-current@freebsd.org, Olaf Seibert Subject: Re: 8.0-RC1 NFS client timeout issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 14:10:48 -0000 On Wed 28 Oct 2009 at 16:38:27 -0400, Rick Macklem wrote: > I'll leave this one for the TCP wizzards. I'm not sure what the > correct behaviour is when data is received on a connection. (I think > it is waiting for a FIN from the client side at this point.) After writing, I realised that it is indeed perfectly allowed for the client to send data. But since the server already sent its FIN, it can't send anything more, not even an error message. So with that in mind, the client shouldn't send anything any more either. > If you could try the following patch and see if it helps, that would be > appreciated, rick Thanks, it looks like it should do the trick. I can't try it before monday, though. -Olaf. --