From owner-freebsd-bugs@FreeBSD.ORG Wed Dec 17 05:20:03 2008 Return-Path: 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 55129106564A for ; Wed, 17 Dec 2008 05:20:03 +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 459B38FC14 for ; Wed, 17 Dec 2008 05:20:03 +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 mBH5K37f097293 for ; Wed, 17 Dec 2008 05:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBH5K3mZ097292; Wed, 17 Dec 2008 05:20:03 GMT (envelope-from gnats) Date: Wed, 17 Dec 2008 05:20:03 GMT Message-Id: <200812170520.mBH5K3mZ097292@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Dieter Cc: Subject: Re: kern/118093: 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 List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2008 05:20:03 -0000 The following reply was made to PR kern/118093; it has been noted by GNATS. From: Dieter To: freebsd-firewire@FreeBSD.org, freebsd-drivers@FreeBSD.org, bug-followup@FreeBSD.org Cc: Subject: Re: kern/118093: firewire bus reset hogs CPU, causing data to be lost Date: Tue, 16 Dec 2008 19:29:13 +0000 Sean> Which file in dev/firewire are you looking at? fwohci.c and firewire.c examples: printf("non CYCLEMASTER mode\n"); device_printf(fc->dev, "Initiate bus reset\n"); ------------------- Warner> This can't be the case. There's no SPL involved at all. Maybe Warner> removing the printfs causes an interrupt to be serviced faster, Warner> resulting in what appears to be better performance... With the printfs, Ethernet is not getting serviced. This is repeatable and easily reproduced. Without the printfs, it seems ok. If it isn't spl, what is locking out Ethernet?