Date: Fri, 9 Nov 2007 21:46:21 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Matt Reimer <mattjreimer@gmail.com> Cc: net@freebsd.org Subject: Re: Should syncache.count ever be negative? Message-ID: <20071109213846.O46803@odysseus.silby.com> In-Reply-To: <f383264b0711091609n81875b6v444055960ab0fd96@mail.gmail.com> References: <f383264b0711091609n81875b6v444055960ab0fd96@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 9 Nov 2007, Matt Reimer wrote: > On a eight core machine running RELENG_7 I'm seeing TCP stalls, > sometimes lasting up to 60 seconds or so. While trying to track this > down I noticed that net.inet.tcp.syncache.count is negative. Should it > be possible for the count to go negative? Perhaps it indicates a race, > or the counter is wrongly being decremented twice? I just took a look at the code, and you are correct that the count is not locked; it looks like you're hitting the race. However, it doesn't look like anything is checking the count, so that should not be the cause of your TCP stalls. Can you install netperf and run both the TCP_STREAM and UDP_STREAM tests just to make sure that your network card is working properly? We've recently found that the fast interrupt handlers we use in some network drivers act strangely when sharing interrupts. So, that's a first thing to test before we poke at the upper layers. If that doesn't help, can you post more details about how you are stressing the system? Thanks, -Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071109213846.O46803>