From: Steven Rostedt <rostedt@goodmis.org>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Ingo Molnar <mingo@kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: ftrace: function radeon_init not traceable
Date: Mon, 11 May 2020 19:30:28 -0400 [thread overview]
Message-ID: <20200511193028.3551d838@oasis.local.home> (raw)
In-Reply-To: <d38aacb6-58ef-b1e5-431b-c945380d20cc@molgen.mpg.de>
On Tue, 12 May 2020 01:07:44 +0200
Paul Menzel <pmenzel@molgen.mpg.de> wrote:
> >>
> >> initcall_debug log_buf_len=32M trace_buf_size=57074K trace_clock=global trace_options=nooverwrite,funcgraph-abstime,funcgraph-cpu,funcgraph-duration,funcgraph-proc,funcgraph-tail,nofuncgraph-overhead,context-info,graph-time ftrace=function_graph ftrace_graph_max_depth=1 ftrace_graph_filter=radeon_init
> >>
> >> But ftrace “rejects” that:
> >>
> >> [ 0.075538] ftrace: allocating 30958 entries in 61 pages
> >> [ 0.084542] ftrace: allocated 61 pages with 5 groups
> >> [ 0.094184] ftrace: function radeon_init not traceable
> >>
> >> I believe it worked in the past. Is there a way to trace that init function?
> >
> > Did it every work for modules? radeon_init() isn't in the symbol table at
> > boot up.
> >
> > [ 15.066951] systemd-journald[124]: Successfully sent stream file descriptor to service manager.
> > [ 15.098265] hub 1-0:1.0: USB hub found
> > [ 15.104006] systemd-journald[124]: Successfully sent stream file descriptor to service manager.
> > [ 15.112965] hub 1-0:1.0: 2 ports detected
> > [ 15.118116] probe of 1-0:1.0 returned 1 after 19873 usecs
> > [ 15.124007] calling radeon_init+0x0/0x1000 [radeon] @ 133
> >
> > The radeon_init is called after systemd is running, so it is definitely
> > from a module.
> >
> > Perhaps you had it built in before?
>
> You are right. Probably I did. Can you suggest how to set up ftrace to
> trace a module?
In recent kernels there was a feature to function trace modules before
they are loaded, but that feature isn't yet available on mainline. I
could add it when I get a chance, but that wont be in the near future.
Also, the function graph wont work for that either, as that isn't set
up to preload before functions. But since you have
ftrace_graph_max_depth of one, you don't need the graph, the limiting
of the function (set_ftrace_filter) is good enough. But again, that
only works after boot up.
> >
> > Probably because the filtering failed, so there is no filter.
>
> Is that the intended behavior? Or should nothing be traced?
Well, it's just like writing something not acceptable in the filter
functions. If it fails, it does not filter. So yes, it is expected
behavior.
-- Steve
prev parent reply other threads:[~2020-05-11 23:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-09 10:16 ftrace: function radeon_init not traceable Paul Menzel
2020-05-11 18:58 ` Steven Rostedt
2020-05-11 23:07 ` Paul Menzel
2020-05-11 23:30 ` Steven Rostedt [this message]
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=20200511193028.3551d838@oasis.local.home \
--to=rostedt@goodmis.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pmenzel@molgen.mpg.de \
/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;
as well as URLs for NNTP newsgroup(s).