From owner-freebsd-current@FreeBSD.ORG Sun Nov 29 19:13:49 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 48EF91065676; Sun, 29 Nov 2009 19:13:49 +0000 (UTC) (envelope-from ltning@anduin.net) Received: from mail.anduin.net (mail.anduin.net [213.225.74.249]) by mx1.freebsd.org (Postfix) with ESMTP id 06C168FC12; Sun, 29 Nov 2009 19:13:48 +0000 (UTC) Received: from [212.62.248.150] (helo=[192.168.2.110]) by mail.anduin.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NEpDO-000GM4-VC; Sun, 29 Nov 2009 20:13:47 +0100 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Eirik_=D8verby?= In-Reply-To: Date: Sun, 29 Nov 2009 20:13:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <20F5AABC-C98D-4D64-AAE3-D87D0C21B8C1@anduin.net> References: <20091129013026.GA1355@michelle.cdnetworks.com> <74BFE523-4BB3-4748-98BA-71FBD9829CD5@anduin.net> To: Robert Watson X-Mailer: Apple Mail (2.1077) Cc: pyunyh@gmail.com, weldon@excelsusphoto.com, freebsd-current@freebsd.org, Gavin Atkinson Subject: Re: FreeBSD 8.0 - network stack crashes? 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: Sun, 29 Nov 2009 19:13:49 -0000 On 29. nov. 2009, at 15.29, Robert Watson wrote: > On Sun, 29 Nov 2009, Eirik =D8verby wrote: >=20 >> I just did that (-rxcsum -txcsum -tso), but the numbers still keep = rising. I'll wait and see if it goes down again, then reboot with those = values to see how it behaves. But right away it doesn't look too good .. >=20 > It would be interesting to know if any of the counters in the output = of netstat -s grow linearly with the allocation count in netstat -m. = Often times leaks are associated with edge cases in the stack (typically = because if they are in common cases the bug is detected really quickly!) = -- usually error handling, where in some error case the unwinding fails = to free an mbuf that it should free. These are notoriously hard to = track down, unfortunately, but the stats output (especially where delta = alloc is linear to delta stat) may inform the situation some more. I'm collecting the output of netstat -m|grep "mbuf clusters" and netstat = -s every 10 seconds now. Will allow it to run until the box stops = responding. Not sure what to do with the data after the box has "died" = .. Will try to see if there are any obvious similarities. Suggestions welcome - both how to collect data and how to analyse ;) /Eirik