[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170717204517.31ae2039@gandalf.local.home>
Date: Mon, 17 Jul 2017 20:45:17 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Will Hawkins <hawkinsw@...laugic.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: Help with trace-cmd/ftrace recording process ID information
On Mon, 17 Jul 2017 18:31:14 -0400
Will Hawkins <hawkinsw@...laugic.com> wrote:
> > It may be that it stopped and never started again, so you will only
> > have a stale file.
>
> This appears to have been the problem! I did a reboot and everything
> is back to normal.
>
> Is there a way to poke at the tracing infrastructure in the kernel to
> get it to restart process recording? I would feel more comfortable
> with a solution like that instead of rebooting, obviously. The 'ol
> Windows "solution" makes me queazy :-)
Well, that's what happens when you run older kernels ;-)
The best I can do is to find the commit that fixed the issue and have
it back ported. Or you can try that. Start with the code that reads and
writes to saved_cmdlines and that will lead you to the map table. You
also need to look where the sched_switch tracepoint gets enabled and
disabled. It uses a ref count to know to enable and disable it, and the
ref count probably got out of sync. Need to find the place that
disabled it twice or something.
One way is to read the commits that affect all that since your kernel.
-- Steve
>
> Thanks again for your quick responses. I hope that I can repay you at
> some point by contributing code to the great tools you've built!
>
> Will
>
> >
> > -- Steve
Powered by blists - more mailing lists