From owner-freebsd-firewire@FreeBSD.ORG  Tue Dec 16 05:10:10 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 B752610656F1
	for <freebsd-firewire@freebsd.org>;
	Tue, 16 Dec 2008 05:10:04 +0000 (UTC)
	(envelope-from freebsd@sopwith.solgatos.com)
Received: from sopwith.solgatos.com
	(pool-71-182-69-106.ptldor.fios.verizon.net [71.182.69.106])
	by mx1.freebsd.org (Postfix) with ESMTP id 9896F8FC14
	for <freebsd-firewire@freebsd.org>;
	Tue, 16 Dec 2008 05:10:02 +0000 (UTC)
	(envelope-from freebsd@sopwith.solgatos.com)
Received: by sopwith.solgatos.com (Postfix, from userid 66)
	id 5C88E3F22; Mon, 15 Dec 2008 20:53:55 -0800 (PST)
Received: from localhost by sopwith.solgatos.com (8.8.8/6.24)
	id DAA27074; Mon, 15 Dec 2008 03:30:04 GMT
Message-Id: <200812150330.DAA27074@sopwith.solgatos.com>
To: freebsd-firewire@freebsd.org, freebsd-drivers@freebsd.org
Date: Sun, 14 Dec 2008 19:30:04 +0000
From: Dieter <freebsd@sopwith.solgatos.com>
Cc: bug-followup@FreeBSD.org
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: Tue, 16 Dec 2008 05:10:10 -0000

I found the source of this problem.  When a firewire bus resets,
the firewire driver prints a few lines to the console,
using printf(9) and device_printf(9).  I suspect that these are
running at splfw aka splimp, locking out other i/o.

Commenting out the *printf() calls fixes the problem, but that
isn't a good solution.

Would changing the *printf() calls to log(9) calls be safe?
("safe" meaning other i/o doesn't get locked out)

Ah, for the good old days when 19200 baud seemed fast...