Messages in this thread | | | Subject | Re: Crash in msm serial on dragonboard with ftrace bootargs | From | Sai Prakash Ranjan <> | Date | Tue, 16 Oct 2018 23:06:24 +0530 |
| |
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
| |