Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Dec 2008 23:59:41 -0700 (MST)
From:      "M. Warner Losh" <imp@bsdimp.com>
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 
Message-ID:  <20081216.235941.1266245051.imp@bsdimp.com>
In-Reply-To: <200812170329.DAA17848@sopwith.solgatos.com>
References:  <4947EAB0.3020704@miralink.com> <200812170329.DAA17848@sopwith.solgatos.com>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200812170329.DAA17848@sopwith.solgatos.com>
            Dieter <freebsd@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...

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081216.235941.1266245051.imp>