From owner-freebsd-current@FreeBSD.ORG  Sat Feb 23 09:37:20 2008
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 00F7716A404
	for <freebsd-current@freebsd.org>; Sat, 23 Feb 2008 09:37:20 +0000 (UTC)
	(envelope-from kris@FreeBSD.org)
Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id 09FC913C442;
	Sat, 23 Feb 2008 09:37:17 +0000 (UTC)
	(envelope-from kris@FreeBSD.org)
Message-ID: <47BFE94D.1070800@FreeBSD.org>
Date: Sat, 23 Feb 2008 10:37:17 +0100
From: Kris Kennaway <kris@FreeBSD.org>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: Bryan Venteicher <bryanv@daemoninthecloset.org>
References: <330977318.1351203756607522.JavaMail.root@zimbra>
In-Reply-To: <330977318.1351203756607522.JavaMail.root@zimbra>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-current@freebsd.org
Subject: Re: panic: lock (smbsm) lockmgr does not match earlier (sleep mutex)
 lock
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Feb 2008 09:37:20 -0000

Bryan Venteicher wrote:
> Hi,
> 
> I receive the following panic "lock (smbsm) lockmgr does not match earlier (sleep mutex) lock" when loading the smbfs module on a recent current.
> 
> Kernel dumps weren't configured on the particular machine. Here's the abbreviated relevant portions of the stack:
> ...
> nsmb_dev_load
> smb_sm_init
> smb_co_init
> ...
> enroll
> panic
> 
> In smb_co_init(), the same description/name is used to initialize both cp->co_interlock and cp->co_lock.

Fix is probably to just rename one so witness doesn't get confused :)

Kris