From owner-freebsd-bugs@FreeBSD.ORG  Wed Jan  7 05:20:02 2009
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Delivered-To: freebsd-bugs@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id BEE761065677
	for <freebsd-bugs@hub.freebsd.org>;
	Wed,  7 Jan 2009 05:20:02 +0000 (UTC)
	(envelope-from gnats@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id AC4DF8FC12
	for <freebsd-bugs@hub.freebsd.org>;
	Wed,  7 Jan 2009 05:20:02 +0000 (UTC)
	(envelope-from gnats@FreeBSD.org)
Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n075K2vo052304
	for <freebsd-bugs@freefall.freebsd.org>; Wed, 7 Jan 2009 05:20:02 GMT
	(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n075K2JK052303;
	Wed, 7 Jan 2009 05:20:02 GMT (envelope-from gnats)
Date: Wed, 7 Jan 2009 05:20:02 GMT
Message-Id: <200901070520.n075K2JK052303@freefall.freebsd.org>
To: freebsd-bugs@FreeBSD.org
From: Dieter <freebsd@sopwith.solgatos.com>
Cc: 
Subject: Re: kern/118093: [firewire] firewire bus reset hogs CPU,
	causing data to be lost 
X-BeenThere: freebsd-bugs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Dieter <freebsd@sopwith.solgatos.com>
List-Id: Bug reports <freebsd-bugs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bugs>,
	<mailto:freebsd-bugs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-bugs>
List-Post: <mailto:freebsd-bugs@freebsd.org>
List-Help: <mailto:freebsd-bugs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bugs>,
	<mailto:freebsd-bugs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jan 2009 05:20:03 -0000

The following reply was made to PR kern/118093; it has been noted by GNATS.

From: Dieter <freebsd@sopwith.solgatos.com>
To: bug-followup@FreeBSD.org, freebsd-firewire@FreeBSD.org
Cc:  
Subject: Re: kern/118093: [firewire] firewire bus reset hogs CPU, causing data to be lost 
Date: Tue, 06 Jan 2009 09:33:21 +0000

 In message <1231222803.21260.17.camel@localhost.localdomain>, Sean Bruno writes:
 
 > > >  	uint32_t fun;
 > > >  
 > > > +	FW_GLOCK(fc);
 > > >  	device_printf(fc->dev, "Initiate bus reset\n");
 > > >  	sc = (struct fwohci_softc *)fc;
 > > >  
 > > > @@ -2487,6 +2495,7 @@
 > > >  	fun |= FW_PHY_ISBR | FW_PHY_RHB;
 > > >  	fun = fwphy_wrdata(sc, FW_PHY_ISBR_REG, fun);
 > > >  #endif
 > > > +	FW_GUNLOCK(fc);
 > > >  }
 > > 
 > > Does the lock need to protect the printf?
 > 
 > These are gross, overpowered, way to heavy handed locks that I'm playing
 > with.  I need to prevent pre-emption of certain events while they are in
 > progress.  One of these events is the firewire's assertion of "bus
 > reset" on the firewire device.  I see the h/w interrupt firing before
 > this code can actually complete, causing the driver to be confused on
 > occasion.
 
 I understand the basic concept of locking, or at least I did many many years
 ago when spls really were levels.  Since then they changed spls to not be levels
 (at least that's what the man page says) and later replaced with mutex.  I assume
 these changes are at least in part to better support SMP.
 
 What I don't understand is things like getting a lock and immediately releasing
 it, which appears to me to protect nothing.  Or why the printf needs to be inside
 the locked section of code.  I thought the goal was to hold a lock for as short a
 time as possible, and it is not clear to me why the printf needs to be protected.