From owner-freebsd-firewire@FreeBSD.ORG  Mon Dec 29 07:33:24 2008
Return-Path: <owner-freebsd-firewire@FreeBSD.ORG>
Delivered-To: freebsd-firewire@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 4D432106564A;
	Mon, 29 Dec 2008 07:33:24 +0000 (UTC)
	(envelope-from freebsd@sopwith.solgatos.com)
Received: from sopwith.solgatos.com
	(pool-71-117-207-61.ptldor.fios.verizon.net [71.117.207.61])
	by mx1.freebsd.org (Postfix) with ESMTP id BBF2F8FC17;
	Mon, 29 Dec 2008 07:33:23 +0000 (UTC)
	(envelope-from freebsd@sopwith.solgatos.com)
Received: by sopwith.solgatos.com (Postfix, from userid 66)
	id A330DB650; Sun, 28 Dec 2008 23:26:57 -0800 (PST)
Received: from localhost by sopwith.solgatos.com (8.8.8/6.24)
	id HAA23593; Mon, 29 Dec 2008 07:30:55 GMT
Message-Id: <200812290730.HAA23593@sopwith.solgatos.com>
To: freebsd-firewire@freebsd.org, bug-followup@freebsd.org
In-reply-to: Your message of "Sun, 28 Dec 2008 22:22:26 PST."
	<49586CA2.60907@miralink.com> 
Date: Sun, 28 Dec 2008 23:30:55 +0000
From: Dieter <freebsd@sopwith.solgatos.com>
Cc: 
Subject: Re: kern/118093: firewire bus reset hogs CPU,
	causing data to be lost 
X-BeenThere: freebsd-firewire@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Firewire support in FreeBSD <freebsd-firewire.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-firewire>, 
	<mailto:freebsd-firewire-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-firewire>
List-Post: <mailto:freebsd-firewire@freebsd.org>
List-Help: <mailto:freebsd-firewire-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-firewire>, 
	<mailto:freebsd-firewire-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Dec 2008 07:33:24 -0000

> > I'll rephrase my question.  In the old days, locking was done with spl.
> > The new way is with mutex.  But with the spl calls being replaced with
> > noops, and as far as I can tell the driver is not using mutex, there
> > doesn't appear to be any locking.  So the driver can step on itself.
> 
> 
> Well, there is locking around a couple of mutex's via FW_GLOCK().

Ah, I wasn't grepping for the right string.  So there *is* mutex
locking.  Although the lingering spl calls are still troubling.