From owner-freebsd-drivers@FreeBSD.ORG Tue Dec 16 05:23:48 2008 Return-Path: <owner-freebsd-drivers@FreeBSD.ORG> Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEB991065673; Tue, 16 Dec 2008 05:23:48 +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 ACA478FC1B; Tue, 16 Dec 2008 05:23:48 +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-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD <freebsd-drivers.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-drivers>, <mailto:freebsd-drivers-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-drivers> List-Post: <mailto:freebsd-drivers@freebsd.org> List-Help: <mailto:freebsd-drivers-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-drivers>, <mailto:freebsd-drivers-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 16 Dec 2008 05:23:49 -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...