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.
Does it break if the crypto is not initialized? Perhaps add a command
line flag to have it happen earlier:
I didnt see any breakage, have been using ramoops with postcore_initcall
for sometime now.
ramoops=earlyinit
and add a postcore_initcall that checks if that flag is set, and if so,
it does the work then, and the late_initcall() will do nothing.
That way, you can still have unmodified kernels use pstore when it
crashes at boot up.
Sounds good.
Great, I guess you can write a patch to do that ;-)
Sure I can :) but as Kees said it would be better if we could
find a way to make it work with a late initialization of compression.
I will try on that.
Thanks,
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
