From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 12:02:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D631716A4CE for ; Wed, 29 Sep 2004 12:02:50 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85D5B43D1D for ; Wed, 29 Sep 2004 12:02:50 +0000 (GMT) (envelope-from marchenko@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so71668rnk for ; Wed, 29 Sep 2004 05:02:41 -0700 (PDT) Received: by 10.38.181.36 with SMTP id d36mr413478rnf; Wed, 29 Sep 2004 05:02:40 -0700 (PDT) Received: by 10.38.22.66 with HTTP; Wed, 29 Sep 2004 05:02:40 -0700 (PDT) Message-ID: Date: Wed, 29 Sep 2004 08:02:40 -0400 From: Vlad To: Robert Watson In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4159431F.6010502@ispro.net.tr> cc: freebsd-current@freebsd.org cc: Evren Yurtesen Subject: Re: panic: sorele X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Vlad List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2004 12:02:51 -0000 > 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