From owner-freebsd-current@FreeBSD.ORG Sun Feb 3 17:03:57 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B8295530; Sun, 3 Feb 2013 17:03:57 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CEDAE117; Sun, 3 Feb 2013 17:03:56 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA09315; Sun, 03 Feb 2013 19:03:52 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U22yu-0006ko-C9; Sun, 03 Feb 2013 19:03:52 +0200 Message-ID: <510E9877.5000701@FreeBSD.org> Date: Sun, 03 Feb 2013 19:03:51 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Rick Macklem , Sergey Kandaurov Subject: Re: panic: LK_RETRY set with incompatible flags References: <74133619.2630890.1359909414548.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <74133619.2630890.1359909414548.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 03 Feb 2013 17:03:57 -0000 on 03/02/2013 18:36 Rick Macklem said the following: > I can think of two possibilities: > 1 - ZFS isn't setting VV_ROOT on the root vnode under some condition. > or > 2 - The vnode was left locked from some previous operation that happened > to be done by this thread. Doesn't seem likely, but??? > > Maybe Sergey could try the change to line#1451 and see if the panic > still happens. If not, that would suggest possibility #1, I think. If the kernel is configured with witness, then it should be easy to check where the exclusive lock was taken (file and line number). -- Andriy Gapon