From owner-freebsd-net@FreeBSD.ORG Mon Aug 9 13:03:45 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1D0B1065672 for ; Mon, 9 Aug 2010 13:03:45 +0000 (UTC) (envelope-from sethj@greatbaysoftware.com) Received: from portcityhosting.com (edge.tidalhosting.net [64.140.243.92]) by mx1.freebsd.org (Postfix) with ESMTP id 800D08FC19 for ; Mon, 9 Aug 2010 13:03:44 +0000 (UTC) Received: from sjeacopello ([173.14.128.81]) by portcityhosting.com with MailEnable ESMTP; Mon, 9 Aug 2010 09:03:43 -0400 X-WatchGuard-Mail-Exception: Allow From: "Seth Jeacopello" To: "'Andre Oppermann'" References: <4C5DE0D5.7090802@freebsd.org> Date: Mon, 9 Aug 2010 09:03:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <4C5DE0D5.7090802@freebsd.org> X-WatchGuard-AntiVirus: part scanned. clean action=allow X-ME-Bayesian: 0.000000 Cc: freebsd-net@freebsd.org Subject: RE: Server sporadically sending unexpected RST to Client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 13:03:46 -0000 Thanks for the quick reply Andre; we have some new information. First I took some time to review some of the tcpdumps per your recommendation and have not found /any/ reuse (with most dumps spanning approx. a one hour time frame and the problem occurring toward the end of the time frame). The client system is another FreeBSD system (we are unsure of the version at this time). You may be correct about the syncache simply showing the symptoms; as we dug deeper we began looking at changes in netisr, in particular the direct dispatch policy modifications. We've run some tests over the weekend and found something that seems to work for us. We've found that moving from 'Always Direct' to 'Hybrid' mode seems to resolve the issue for us without any noticed consequences (setting net.isr.direct_force=0). Can anyone comment on this setting and let us know of any downsides or problems that may occur running in this mode? We believe that this problem is also only isolated to one of our Server platforms (testing on our other platform is still on-going, though initial results look good). Both platforms are Intel based (current generation vs. last generation) with various differences, though the one that may be most relative is the change of the on-board NIC from being 'em' based to 'igb' based (that is the systems with the issue all have 'em' based NICs vs. 'igb' of the newer systems). This could be red-herring as well, though I feel it's probably a good idea to include as much information as possible when troubleshooting. Thank you for all of your help and I look forward to hearing any further thoughts on this issue. --Seth