From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 08:00:14 2008 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 A3F3616A418 for ; Fri, 25 Jan 2008 08:00:14 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 2877B13C47E for ; Fri, 25 Jan 2008 08:00:08 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so599606fgg.35 for ; Fri, 25 Jan 2008 00:00:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=wewvjPSO0aGtD4AABhCDerb+qm+l0BxWea3+jJCkeBk=; b=heZMwst3j4JTMrn2dFkm/V/eoTeBcX/4vyEFBbBHZSHdn0KNQBbTRDWb2MnMwV4iSPRJChyARz//efGqx/8vfvjXA1pzQsMGZ9VFuwsl8nIZgQ2jMjjgBFtqI0iYe53bA6Q9Xcm2OH+vSquV6XCAPU3gKU2uSYgp9nrXiHz81aQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=R24hL/qWNZwjgVuWXzVEpsqPQsrxxJxU9zXc27Qi0aANqCbPFQALb1TVNhbeHrf7ptnQPy6l2b+0kKaMUAzjO2NcWl/GDEN8iHZ3WYrl5HJQ3zaLCPv6tEILIBxBZ4055QC8WhIM+voG+/E7n4Eu6HBGtKydEry1V0huCzb0ZVw= Received: by 10.86.74.15 with SMTP id w15mr1551118fga.46.1201248007843; Fri, 25 Jan 2008 00:00:07 -0800 (PST) Received: by 10.86.53.7 with HTTP; Fri, 25 Jan 2008 00:00:07 -0800 (PST) Message-ID: <3bbf2fe10801250000k5852c2f2j5d1897c900096818@mail.gmail.com> Date: Fri, 25 Jan 2008 09:00:07 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Yar Tikhiy" In-Reply-To: <20080125075551.GB21633@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <790a9fff0801150552l542a4238ofc12efe5fdb45fc2@mail.gmail.com> <20080115143924.GB57756@deviant.kiev.zoral.com.ua> <20080124122808.GA15600@freefall.freebsd.org> <3bbf2fe10801240518i6e18b2f5w84de652d4170c95b@mail.gmail.com> <20080124145811.GB78114@comp.chem.msu.su> <3bbf2fe10801240707o72b927cg74dbf9b7bbcd88fc@mail.gmail.com> <20080125075551.GB21633@comp.chem.msu.su> X-Google-Sender-Auth: 5d22ed6d6bbc235e Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: panic: System call lstat returning with 1 locks held X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2008 08:00:14 -0000 2008/1/25, Yar Tikhiy : > On Thu, Jan 24, 2008 at 04:07:43PM +0100, Attilio Rao wrote: > > 2008/1/24, Yar Tikhiy : > > > On Thu, Jan 24, 2008 at 02:18:56PM +0100, Attilio Rao wrote: > > > > 2008/1/24, Yar Tikhiy : > > > > > On Tue, Jan 15, 2008 at 04:39:24PM +0200, Kostik Belousov wrote: > > > > > > > > > > > > I think this could be related to the recent vn_lock()/VOP_LOCK() KPI changes. > > > > > > Please, add DEBUG_VFS_LOCKS to the kernel config, and do the > > > > > > show lockedvnods > > > > > > from the ddb prompt when the panic occurs. The witness does not track > > > > > > the lockmgr locks. > > > > > > > > > > I think I'm seeing the same panic on UFS. It's rather nasty: I > > > > > cannot rebuild CURRENT natively due to it so I have to build it > > > > > under 6-STABLE. My favourite way to trigger the panic reliably is > > > > > running `make install' in a simple port directory, e.g., portmaster, > > > > > but my system also panics during daily scripts run and, as already > > > > > said, if trying to build world. > > > > > > > > Yar, > > > > as it seems reproducible for you, can you please add this patch to the tree: > > > > http://www.freebsd.org/~attilio/debug_tdlocks.diff > > > > > > > > compile your kernel with: > > > > options KTR > > > > options KTR_COMPILE=(KTR_SPARE2) > > > > options KTR_MASK=(KTR_SPARE2) > > > > options KTR_ENTRIES=32768 > > > > > > > > and once kernel panics, at ddb prompts do: > > > > > show ktr > > > > > > Thank you for your instant response! > > > > > > The patched kernel is already being built, but I've got the following > > > question in the meanwhile: Should I have updated my kernel to get your > > > latest changes to kern_lock.c? Now my local copy of kern_lock.c is at > > > rev. 1.119, i.e., 1 revision behind today's change. > > > > As long as this patch still applies, it should not any meaningful difference. > > > > Thanks a lot for your effort of testing and reporting bugs! > > I don't deserve these kind words because I disinformed you seriously. > > My panic appears to be related not to UFS, but to NTFS. Namely I > have an NTFS volume mounted read-only at /ntfs. I have no idea why > the ports framework touches the /ntfs sub-tree, but not mounting > it in the first place makes the panic go away. (I still wonder why > my system would also panic during buildworld, which should not touch > my /ntfs at all... Now I'll try to do a buildworld w/o /ntfs mounted.) Well, this is still to be fixed :) > At the same time, dismounting the NTFS volume leads to an instant > panic of a similar kind: > > panic: System call unmount returning with 5 locks held > > More debug output is attached. > > So at least UFS doesn't seem affected by the panic. Excuse me for > my having provided wrong info. > > -- > Yar > > panic: System call unmount returning with 5 locks held > cpuid = 0 > KDB: enter: panic > [thread pid 985 tid 100085 ] > Stopped at kdb_enter+0x3a: movl $0,kdb_why > db> show lockedvn > Locked vnodes > db> sh ktr > 678 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of -1 td_locks > 677 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of -1 td_locks > 676 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of -1 td_locks > 675 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of 1 td_locks > 674 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of -1 td_locks > 673 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of 1 td_locks > 672 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of -1 td_locks > 671 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of 1 td_locks > 670 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of -1 td_locks > 669 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of 1 td_locks > 668 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of -1 td_locks > 667 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of 1 td_locks > 666 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of -1 td_locks > 665 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of 1 td_locks > 664 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of -1 td_locks > 663 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of 1 td_locks > 662 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of -1 td_locks > 661 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of 1 td_locks > 660 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of -1 td_locks > 659 (0xc37dd000:cpu0): _lockmgr: 0xc37dd000 bumping of 1 td_locks > db> where > Tracing pid 985 tid 100085 td 0xc37dd000 > kdb_enter(c0b0c893,c0b0c893,c0b3ce37,d639cc8c,0,...) at kdb_enter+0x3a > panic(c0b3ce37,c0b2b59e,5,c0b2b59e,c0bbef10,...) at panic+0x12c > syscall(d639cd38) at syscall+0x46e > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (0, FreeBSD ELF32, nosys), eip = 0x280c4bbb, esp = 0xbfbfe59c, ebp = 0xbfbfe658 --- Do you see any call to lockmgr_disown() in this ktr trace? Can you past relevant lines of it, otherwise? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein