From: Steven Rostedt <rostedt@goodmis.org>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc: linux-trace-kernel@vger.kernel.org,
Masami Hiramatsu <mhiramat@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Pengutronix Kernel Team <kernel@pengutronix.de>
Subject: Re: Boot-time dumping of ftrace fuctiongraph buffer
Date: Thu, 1 Feb 2024 20:46:37 -0500 [thread overview]
Message-ID: <20240201204637.2afab2db@gandalf.local.home> (raw)
In-Reply-To: <d33e5271-219d-4b8e-be5a-8903219d7fd6@pengutronix.de>
On Thu, 1 Feb 2024 13:21:37 +0100
Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> Hello,
>
> I semi-regularly debug probe failures. For drivers that use dev_err_probe
> rigorously, this is a quick matter: The probe function records a deferral reason
> and if the deferral persists, deferred_probe_timeout_work_func() will print
> the collected reasons, even if PID 1 is never started.
>
> For drivers that don't call dev_err_probe, I find myself sometimes doing printf
> debugging inside the probe function.
Is the driver built in or started after init?
>
> I would like to replace this with the function graph tracer:
>
> - record the probe function, configured over kernel command line
> (The device indefinitely deferring probe is printed to the console,
> so I know what I am looking for on the next boot)
>
> - Dump the function graph trace
>
> - See if the last call before (non-devm) cleanup is getting a clock, a GPIO,
> a regulator or w/e.
>
> For this to be maximally useful, I need to configure this not only at boot-time,
> but also dump the ftrace buffer at boot time. Probe deferral can hinder the kernel from
> calling init and providing a shell, where I could read /sys/kernel/tracing/trace.
OK so the driver is built in.
>
> I found following two mechanisms that looked relevant, but seem not to
> do exactly what I want:
>
> - tp_printk: seems to be related to trace points only and not usable
> for the function graph output
>
> - dump_on_oops: I don't get an Oops if probe deferral times out, but maybe
> one could patch the kernel to check a oops_on_probe_deferral or dump_on_probe_deferral
> kernel command line parameter in deferred_probe_timeout_work_func()?
>
>
> Is there existing support that I am missing? Any input on whether this
> would be a welcome feature to have?
Well you can start function_graph on the kernel command line and event
filter on a give function
ftrace=function_graph function_graph_filter=probe_func
You can add your own ftrace_dump() on some kind of detected error and put
that in the kernel command line. For example RCU has:
rcupdate.rcu_cpu_stall_ftrace_dump=
Which will do a ftrace dump when a RCU stall is triggered.
-- Steve
next prev parent reply other threads:[~2024-02-02 1:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-01 12:21 Boot-time dumping of ftrace fuctiongraph buffer Ahmad Fatoum
2024-02-02 1:46 ` Steven Rostedt [this message]
2024-02-02 13:19 ` Ahmad Fatoum
2024-02-02 6:04 ` Masami Hiramatsu
2024-02-02 13:12 ` Ahmad Fatoum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240201204637.2afab2db@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=a.fatoum@pengutronix.de \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox