From: "Guilherme G. Piccoli" <gpiccoli@canonical.com>
To: anton@enomsg.org, joel@joelfernandes.org
Cc: Kees Cook <keescook@chromium.org>,
ccross@android.com, tony.luck@intel.com,
Steven Rostedt <rostedt@goodmis.org>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
u.kleine-koenig@pengutronix.de
Subject: About ftrace+pstore+ramoops
Date: Thu, 26 Nov 2020 18:33:09 -0300 [thread overview]
Message-ID: <72df55ca-20f3-c3ee-861b-c50c1a55495e@canonical.com> (raw)
Hi Anton / Joel (and all CCed), sorry for annoyance but I'm not being
able to make pstore ftrace capture to work - I'm not sure if I might be
missing something, or if there's a known limitation.
So, first, my use case: I'd like to be able to collect *ftrace* trace
buffer in a specific point in time, when some issue I'm facing happens;
for that, I enable ftrace through tracing_on() in the correct point in
the code. After this issue, machine is not responsive, so I need to
reboot (hence I'd like to persist the trace buffer in my ramoops
reserved area).
For the basic test purpose though, I'm doing just what is suggested in
the ramoops documentation, which is to write 1 on
<debugfs>/pstore/record_ftrace and reboot - but no ftrace file is
present in the pstore folder after the reboot. I've tested the same
system/config by inducing a kernel oops and the corresponding
dmesg-ramoops file is there after the reboot...
Just for clarification: this ftrace feature in pstore is meant to do
what I want right? It should *always* collect the same information as
seen in the trace buffer, but on the persistent memory region configured
by ramoops, correct?
Any guidance you can provide me is much appreciated.
Thanks in advance,
Guilherme
next reply other threads:[~2020-11-26 21:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-26 21:33 Guilherme G. Piccoli [this message]
2020-11-26 22:20 ` Guilherme Piccoli
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=72df55ca-20f3-c3ee-861b-c50c1a55495e@canonical.com \
--to=gpiccoli@canonical.com \
--cc=anton@enomsg.org \
--cc=ccross@android.com \
--cc=joel@joelfernandes.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tony.luck@intel.com \
--cc=u.kleine-koenig@pengutronix.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
all inboxes | Powered by JetHome®