From owner-freebsd-current@FreeBSD.ORG Wed Aug 10 06:31:25 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org 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 9C91F16A41F; Wed, 10 Aug 2005 06:31:25 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AB8A43D46; Wed, 10 Aug 2005 06:31:25 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by postfix3-2.free.fr (Postfix) with ESMTP id 4B337C077; Wed, 10 Aug 2005 08:31:24 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j7A6VIAN014903; Wed, 10 Aug 2005 08:31:21 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Wed, 10 Aug 2005 08:31:09 +0200 User-Agent: KMail/1.8.2 References: <200508100611.j7A6B6qf099212@gw.catspoiler.org> In-Reply-To: <200508100611.j7A6B6qf099212@gw.catspoiler.org> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200508100831.11384.thierry@herbelot.com> Cc: kan@freebsd.org, Don Lewis Subject: Re: panic: lock (sleep mutex) vnode interlock not locked X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2005 06:31:25 -0000 Le Wednesday 10 August 2005 08:11, Don Lewis a écrit : > > I also noticed this inconsistency in vgonel() a couple hours ago and > made exactly the same change in my local source. No problems so far, > but I suspect this bug is difficult to trigger. It's been present in As I wrote before, I saw it twice yesterday - it was in the initial "rm -r" phase of "make buildworld" > the code for a couple of months. maybe a code change "elsewhere" made it more probable (the LOCK/UNLOCK infrastructure everywhere in the kernel code begins to be scary : difficult to follow, difficult to prove right ?) TfH