Date: Wed, 29 Sep 2004 08:02:40 -0400 From: Vlad <marchenko@gmail.com> To: Robert Watson <rwatosn@freebsd.org> Cc: Evren Yurtesen <yurtesen@ispro.net.tr> Subject: Re: panic: sorele Message-ID: <cd70c681040929050230e7b6fa@mail.gmail.com> In-Reply-To: <Pine.NEB.3.96L.1040928232554.15557D-100000@fledge.watson.org> References: <4159431F.6010502@ispro.net.tr> <Pine.NEB.3.96L.1040928232554.15557D-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> If you compile a kernel with NET_WITH_GIANT but keep SMP, does the problem > persist? > I'll give it a try. > Are you using Netgraph or any other non-default kernel compile options > relating to the network stack? Do you make moderate or extensive use of > IPv6? no > This is a somewhat odd assertion failure: sodealloc() asserts that > so_count is 0, but so does sofree(), and sofree() is only called by > sotryfree() in in_pcbdetach() if so_count is 0. This suggests that either > (a) we're looking at a race in which so_count is bumped in that window, or > (b) there's a problem with the compile of the kernel where the invariants > checks may be compiled into some objects but not others. In theory, > locking should prevent (a), so if it is (a) there's a bug in the locking. > I'll start reviewing use of so_count and work my way through the rest of > this thread. Knowing if compiling with NET_WITH_GIANT helps would be > useful, if possible. I'll keep list posted. -- Vlad
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cd70c681040929050230e7b6fa>