Date: Fri, 6 Nov 2009 15:40:05 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Olaf Seibert <O.Seibert@cs.ru.nl> Cc: danny@cs.huji.ca.il, dfr@freebsd.org, freebsd-stable@freebsd.org, kometen@gmail.com Subject: Re: 8.0-RC1 NFS client timeout issue Message-ID: <Pine.GSO.4.63.0911061534470.25268@muncher.cs.uoguelph.ca> In-Reply-To: <20091102100958.GY841@twoquid.cs.ru.nl> References: <20091027164159.GU841@twoquid.cs.ru.nl> <Pine.GSO.4.63.0910281624440.18390@muncher.cs.uoguelph.ca> <20091029135239.GX841@twoquid.cs.ru.nl> <Pine.GSO.4.63.0911011713290.23081@muncher.cs.uoguelph.ca> <20091102100958.GY841@twoquid.cs.ru.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Nov 2009, Olaf Seibert wrote: >> Although I think the patch does avoid sending the request on the >> partially closed connection, it doesn't fix the "real problem", >> so I don't know if it is worth testing? > > Well, I tested it anyway, just in case. It seems to work fine for me, so > far. > > I don't see your extra RSTs either. Maybe that is because in my case the > client used a different port number for the new connection. (Usually, > this is controlled by the TCP option SO_REUSEADDR from <sys/socket.h>). > It seems that the pesky RSTs I was seeing were generated by the net chip in the machine I was using (Intel 82801BA/CAM - fxp driver) when TSO was enabled for it. sysctl net.inet.tcp.tso=0 got rid of the problem and, with the patch you already tested, thinks are testing well here. If anyone is still having NFS over TCP reconnect problems after applying the patch, please try the above and see if it helps. Thanks, rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0911061534470.25268>