[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1326901057.17534.77.camel@gandalf.stny.rr.com>
Date: Wed, 18 Jan 2012 10:37:37 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Mike Galbraith <efault@....de>
Cc: Tim Sander <tim.sander@....com>,
Tim Sander <tstone@....tu-darmstadt.de>,
LKML <linux-kernel@...r.kernel.org>,
RT <linux-rt-users@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Clark Williams <williams@...hat.com>,
John Kacur <jkacur@...hat.com>
Subject: Re: [ANNOUNCE] 3.0.14-rt31 - ksoftirq running wild - FEC ethernet
driver to blame? Yep
On Wed, 2012-01-18 at 14:54 +0100, Mike Galbraith wrote:
> On Wed, 2012-01-18 at 12:11 +0100, Tim Sander wrote:
>
> > > If that's it, you can apply the below, do the same edit, and see which
> > > thread is grinding away. From there, I'd set a trap. Let sirq threads
> > > detect that they are being awakened too fast (hey, I can't go to sleep,
> > > the sirq I just processed is busy again, N times in a row) and leave a
> > > note for wakeup_softirqd(). There, WARN_ON(ksoftirqd)[i].help_me) or
> > > such, to see who is flogging which softirq mercilessly.
> > I didn't use this tricks, since top was already doing its job good enough :-).
>
> Ok, you now know which softirq is being flogged, maybe that's enough for
> someone who knows network goop, dunno. If you set the trap, you'll get
> an 8x10 color glossy of the slave driver, whip in hand ;-)
This could be another trylock spin loop. I'll have to have a deeper
look.
Thanks,
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists