From owner-freebsd-bugs@FreeBSD.ORG Wed Dec 17 07:10:04 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 46B1B106564A for ; Wed, 17 Dec 2008 07:10:04 +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 3812D8FC1D for ; Wed, 17 Dec 2008 07:10:04 +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 mBH7A4vH082158 for ; Wed, 17 Dec 2008 07:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBH7A4lD082157; Wed, 17 Dec 2008 07:10:04 GMT (envelope-from gnats) Date: Wed, 17 Dec 2008 07:10:04 GMT Message-Id: <200812170710.mBH7A4lD082157@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: "M. Warner Losh" 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: "M. Warner Losh" List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2008 07:10:04 -0000 The following reply was made to PR kern/118093; it has been noted by GNATS. From: "M. Warner Losh" To: freebsd@sopwith.solgatos.com Cc: freebsd-firewire@freebsd.org, freebsd-drivers@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/118093: firewire bus reset hogs CPU, causing data to be lost Date: Tue, 16 Dec 2008 23:59:41 -0700 (MST) In message: <200812170329.DAA17848@sopwith.solgatos.com> Dieter writes: : 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? interrupt storm? In old-spl-locked drivers, often times the interrupt would be masked while certain operations happened. In new mutex-locked freebsd, there's no way to block the interrupts, so sometimes old code gets into an interrupt storm, which starves other things. Not sure why printf would trigger this, however... Warner