devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Frank Rowand <frowand.list@gmail.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
	devicetree@vger.kernel.org,
	Tyrel Datwyler <tyreld@linux.vnet.ibm.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	linux-renesas-soc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	Rob Herring <robh+dt@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues
Date: Thu, 25 Jan 2018 06:03:30 -0500	[thread overview]
Message-ID: <20180125060330.781667e9@vmware.local.home> (raw)
In-Reply-To: <00fc90ee-de26-f819-9c81-27d06918564d@gmail.com>

On Wed, 24 Jan 2018 22:55:13 -0800
Frank Rowand <frowand.list@gmail.com> wrote:

> Hi Steve,

> 
> Off the top of your head, can you tell me know early in the boot
> process a trace_event can be called and successfully provide the
> data to someone trying to debug early boot issues?

The trace events are enabled by early_initcall().

> 
> Also, way back when version 1 of this patch was being discussed,
> a question about stacktrace triggers:
> 
>      >>> # echo stacktrace > /sys/kernel/debug/tracing/trace_options
>      >>> # cat trace | grep -A6 "/pci@800000020000018"    
>      >>
>      >> Just to let you know that there is now stacktrace event triggers, where
>      >> you don't need to stacktrace all events, you can pick and choose. And
>      >> even filter the stack trace on specific fields of the event.    
>      >
>      > This is great, and I did figure that out this afternoon. One thing I was
>      > still trying to determine though was whether its possible to set these
>      > triggers at boot? As far as I could tell I'm still limited to
>      > "trace_options=stacktrace" as a kernel boot parameter to get the stack
>      > for event tracepoints.  
> 
>      No not yet. But I'll add that to the todo list.
> 
>      Thanks,
> 
>      -- Steve
> 
> Is this still on your todo list, or is it now available?

Still on the todo list. As someone once said, there really is no todo
list, but just work on the stuff that people are yelling the loudest
about. Yell louder, and it will get done quicker ;-)

-- Steve

  reply	other threads:[~2018-01-25 11:03 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-21 14:31 [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues Wolfram Sang
2018-01-21 14:31 ` [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle Wolfram Sang
2018-01-21 22:01   ` Steven Rostedt
2018-01-25  6:48   ` Frank Rowand
2018-01-25  6:58     ` Frank Rowand
     [not found]     ` <4cc627c4-1aaf-b8d5-5a26-eea7e596743f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-25  8:01       ` Geert Uytterhoeven
2018-01-25 22:40     ` Tyrel Datwyler
     [not found]       ` <25f83d0d-bc67-f1b5-cadb-838987fd846d-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-01-25 23:31         ` Frank Rowand
2018-01-25  8:32   ` Frank Rowand
2018-01-22  8:43 ` [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues Frank Rowand
2018-01-22 11:49   ` Wolfram Sang
2018-01-23 12:11     ` Michael Ellerman
2018-01-23 19:53       ` Frank Rowand
2018-01-25  6:47     ` Frank Rowand
     [not found]       ` <11cf8fac-d2fe-ecdb-546f-de3c3b42a637-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-25 23:12         ` Wolfram Sang
2018-01-26  0:42           ` Frank Rowand
2018-01-25  6:48 ` Frank Rowand
     [not found] ` <20180121143117.19805-1-wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/@public.gmane.org>
2018-01-25  6:55   ` Frank Rowand
2018-01-25 11:03     ` Steven Rostedt [this message]
2018-01-25 21:49       ` Frank Rowand
     [not found]         ` <a30d4cd3-0068-8cca-cc2f-ca207d0d278b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-25 23:14           ` Wolfram Sang
2018-01-26  0:46             ` Frank Rowand
2018-02-01 17:10               ` Steven Rostedt
2018-01-25 23:53         ` Tyrel Datwyler
2018-01-26  1:08           ` Frank Rowand

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=20180125060330.781667e9@vmware.local.home \
    --to=rostedt@goodmis.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=robh+dt@kernel.org \
    --cc=tyreld@linux.vnet.ibm.com \
    --cc=wsa+renesas@sang-engineering.com \
    /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).