Date: Mon, 30 Nov 2009 11:36:33 +0100 From: =?iso-8859-1?Q?Eirik_=D8verby?= <ltning@anduin.net> To: Robert Watson <rwatson@FreeBSD.org> Cc: pyunyh@gmail.com, weldon@excelsusphoto.com, freebsd-current@freebsd.org, Gavin Atkinson <gavin@freebsd.org> Subject: Re: FreeBSD 8.0 - network stack crashes? Message-ID: <A0C9ED20-5536-44E2-B26B-0F1AEC2AF79C@anduin.net> In-Reply-To: <34AD565D-814A-446A-B9CA-AC16DD762E1B@anduin.net> References: <A1648B95-F36D-459D-BBC4-FFCA63FC1E4C@anduin.net> <20091129013026.GA1355@michelle.cdnetworks.com> <74BFE523-4BB3-4748-98BA-71FBD9829CD5@anduin.net> <alpine.BSF.2.00.0911291427240.80654@fledge.watson.org> <34AD565D-814A-446A-B9CA-AC16DD762E1B@anduin.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Short follow-up: Making OpenBSD use TCP mounts (it defaults to UDP) = seems to solve the issue. So this is a UDP-NFS-related problem, it would seem? /Eirik On 30. nov. 2009, at 11.22, Eirik =D8verby wrote: > Hi, >=20 > I have something that might be more interesting than any counter ... > It seems to me as if the problem *only* manifests itself when an = OpenBSD box is backing up to this FreeBSD 8.0-NFS-ZFS server. All other = boxes are FreeBSD, and I have so far today been unable to reproduce the = problem from any of those. As soon as I interrupted the backup running = from OpenBSD, the mbuf cluster usage stabilized. >=20 > How's that for a mystery in the morning? >=20 > /Eirik >=20 > On 29. nov. 2009, at 15.29, Robert Watson wrote: >=20 >> 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. >>=20 >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A0C9ED20-5536-44E2-B26B-0F1AEC2AF79C>