kern/118093: firewire bus reset hogs CPU, causing data to be
sbruno at miralink.com
Wed Dec 17 17:20:04 PST 2008
The following reply was made to PR kern/118093; it has been noted by GNATS.
From: Sean Bruno <sbruno at miralink.com>
To: "M. Warner Losh" <imp at bsdimp.com>
Cc: freebsd at sopwith.solgatos.com, freebsd-firewire at freebsd.org,
bug-followup at freebsd.org
Subject: Re: kern/118093: firewire bus reset hogs CPU, causing data to be
Date: Wed, 17 Dec 2008 17:10:53 -0800
M. Warner Losh wrote:
> In message: <200812170329.DAA17848 at sopwith.solgatos.com>
> Dieter <freebsd at sopwith.solgatos.com> 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...
> freebsd-drivers at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-drivers-unsubscribe at freebsd.org"
Let me take a stab at this one this week. There's got to be something
more going on
than a printf() causing hell. It could be a mutex being held causing
The firewire code is my current project, I'll look at this issue now.
More information about the freebsd-bugs