Date: Fri, 6 Nov 2009 22:26:38 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Rui Paulo <rpaulo@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: Help needed: TCP Wizards (was 8.0-RC1 NFS client timeout issue) Message-ID: <Pine.GSO.4.63.0911062220210.16317@muncher.cs.uoguelph.ca> In-Reply-To: <030A8229-9707-4F70-B4BE-584F1BF9ECEC@FreeBSD.org> References: <Pine.GSO.4.63.0911011644410.19276@muncher.cs.uoguelph.ca> <4AF0B7DF.9030405@freebsd.org> <Pine.GSO.4.63.0911051121340.5409@muncher.cs.uoguelph.ca> <030A8229-9707-4F70-B4BE-584F1BF9ECEC@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Nov 2009, Rui Paulo wrote: > > Are you running TSO? > I spoke too soon the last time. It appears that the setting of net.inet.tcp.tso does not have any effect and that the Intel chip on this machine doesn't do TSO. (I tried swapping it for a 3C905 and the RSTs are showing up.) I guess it was just coincidence that the RSTs seemed to stop happening for a while after I flipped the sysctl. I think the problem is related to the fact that the server end has started to close down the connection (send a FIN), but the client doesn't do anything until an RPC shows up and then tried to do a new connection right after shutting down the old one. (Solaris10 generates RSTs on the old connection and it seems that somehow triggers one being sent to the server with the new port# instead of the old port#.) I'm about to try doing a soshutdown() at the time the server sends the FIN to the client, to see what effect that has. I still can't figure out where the pesky RST gets sent or I could get a stack trace at that point and see what is doing it. Having lottsa fun with it, rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0911062220210.16317>