From owner-freebsd-current@FreeBSD.ORG Sat Jul 28 06:33:24 2007 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 79C9316A41A for ; Sat, 28 Jul 2007 06:33:24 +0000 (UTC) (envelope-from thierry@herbelot.com) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.freebsd.org (Postfix) with ESMTP id 2482513C45D for ; Sat, 28 Jul 2007 06:33:24 +0000 (UTC) (envelope-from thierry@herbelot.com) Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id C4A996E03F for ; Sat, 28 Jul 2007 08:33:22 +0200 (CEST) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g19.free.fr (Postfix) with ESMTP id 9357E5CF2 for ; Sat, 28 Jul 2007 08:33:22 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.14.0/8.14.0) with ESMTP id l6S6VfhJ029097; Sat, 28 Jul 2007 08:31:42 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Sat, 28 Jul 2007 08:31:32 +0200 User-Agent: KMail/1.9.7 References: <200707210657.11159.thierry@herbelot.com> <20070727200826.GA53337@dan.emsphone.com> <20070727205634.GA49495@rot26.obsecurity.org> In-Reply-To: <20070727205634.GA49495@rot26.obsecurity.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-15" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200707280831.34518.thierry@herbelot.com> Cc: Dan Nelson , Kris Kennaway Subject: Re: ZFS panic: System call unlink returning with 1 locks held 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: Sat, 28 Jul 2007 06:33:24 -0000 Le Friday 27 July 2007, Kris Kennaway a écrit : > On Fri, Jul 27, 2007 at 03:08:26PM -0500, Dan Nelson wrote: > > In the last episode (Jul 21), Thierry Herbelot said: > > > with a recent -current -built yesterday), I just got a panic while > > > rebuilding -j4 the world and portupgrading firefox. > > > > > > the machine is pretty much memory limited (only 320 MB of RAM), with > > > two CPUs, running a straight GENERIC kernel, including WITNESS and > > > INVARIANTS. > > > > [..] > > > > > the panic message is : > > > > > > panic: System call unlink returning with 1 locks held > > > cpuid = 0 > > > KDB: enter: panic > > > [thread pid 42789 tid 100102 ] > > > Stopped at kdb_enter+0x32: leave > > > db> where > > > Tracing pid 42789 tid 100102 td 0xc2ce3200 > > > kdb_enter(c0a92bc5,0,c0ac0a31,d5457c8c,0,...) at kdb_enter+0x32 > > > panic(c0ac0a31,c0a98f5c,1,c0a98f5c,c0b3f030,...) at panic+0x124 > > > syscall(d5457d38) at syscall+0x46e > > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > > > I've been seeing this, as late as on a Jul 24 kernel. Happened once > > during the cleandir stage of a buildworld, and few more times when the > > system was relatively idle (although it is an mrtg server so lots of > > files are constantly created and rm'd). My system is i386 with 1GB of > > RAM, has a ZFS root, and is SMP. I've also gotten a similar "System > > call rename returning with 1 locks held" panic. Is there any way to > > find out what lock is being held? I've got a couple crashdumps. > > It appears to be a leak in the lock counters somewhere, perhaps > related to recursively acquired rwlocks (e.g. double increment, single > free). I eventually disabled the check because even adding extensive > extra debugging there was no evidence of an actual lock being leaked > anywhere. > > Kris Hello, I saw the same panic once or twice since the first report (same trace, different phases of make buildworld). I had vfs.zfs.zil_disable="1" in /boot/loader.conf, which I just removed. we'll see if the stability improves. TfH --