On 10/16/2018 11:18 PM, Steven Rostedt wrote:
On Tue, 16 Oct 2018 23:06:24 +0530
Sai Prakash Ranjan <saiprakash.ranjan@xxxxxxxxxxxxxx> wrote:
On 10/16/2018 10:27 PM, Steven Rostedt wrote:
OK, can you add to the command line:
ftrace=function ftrace_filter=*schedule*
to see if it's a specific function that may be causing the issue (but
hopefully it's not one of the scheduling functions that caused it).
Target boots fine with this. So its not scheduling functions that is
causing it. Also I tried with ftrace_filter=*msm* just to be sure if
tracing driver functions is causing any issue but its NOT.
OK, seems that something is being traced that shouldn't be.
When this happens after boot up, it's easy to bisect down to the
problem function. But since it's at boot up, it will take a lot longer.
I would suggest to start by going down the alphabet.
ftrace_filter=a*
ftrace_filter=b*
ftrace_filter=c*
[...]
And at least find the letter the bad function starts with.
Note, it could be more than one function (I've had that a couple of
times), and to find that out, you can test with "ftrace_notrace". Say
you find that the problem function starts with 'x'. You can do:
ftrace_notrace=x*
Which will trace all functions except those that start with an 'x', to
make sure it still boots.
Remember, you still need to have ftrace=function for all of this.
Once you find the letter of the function, you can try the next letter,
or perhaps come up with another method. I would say look at the
functions in /sys/kernel/debug/tracing/available_filter_functions, but
they don't list the init function (that can be traced). But you can
use /proc/kallsyms instead.
Ok got it, this sounds fun. I'll give it a try.
Thanks
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
