From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751971AbdGRApV (ORCPT ); Mon, 17 Jul 2017 20:45:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:39624 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751525AbdGRApU (ORCPT ); Mon, 17 Jul 2017 20:45:20 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AD10D22C88 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Mon, 17 Jul 2017 20:45:17 -0400 From: Steven Rostedt To: Will Hawkins Cc: linux-kernel@vger.kernel.org Subject: Re: Help with trace-cmd/ftrace recording process ID information Message-ID: <20170717204517.31ae2039@gandalf.local.home> In-Reply-To: References: <20170717155352.2c94e662@gandalf.local.home> <20170717161712.6bc38c83@gandalf.local.home> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 17 Jul 2017 18:31:14 -0400 Will Hawkins 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