On Tue, 16 Oct 2018 22:05:23 +0530 Sai Prakash Ranjan <saiprakash.ranjan@xxxxxxxxxxxxxx> wrote: > On 10/16/2018 8:59 PM, Steven Rostedt wrote: > > On Tue, 16 Oct 2018 17:08:25 +0530 > > Sai Prakash Ranjan <saiprakash.ranjan@xxxxxxxxxxxxxx> wrote: > > > >> Hi, > >> > >> On dragonboard 410c, with "ftrace=function" boot args, the console > >> output slows down and board resets without any backtrace as below. This > >> is tested on latest kernel and seems to exist even in older kernels as well. > > > > So this only happens when ftrace=function is on the boot console. > > > > Yes. If I do not use boot console, target does not crash. > > > > > Does function tracing work after boot up? That is, without the > > ftrace=function, can you do: > > > > echo function > /sys/kernel/debug/tracing/current_tracer > > > > without any issue? > > > > Yes ftrace in general works without any issue. I have also tested on > db820c and sdm845 where "ftrace=function" works fine. I am seeing this > issue only on db410c board. 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). > > >> > >> One more thing is for pstore dmesg-ramoops, I had to change > >> late_initcall to postcore_initcall which brings the question as to why > >> we changed to late_initcall? > >> Simple git blame shows to support crypto compress api, but is it really > >> helpful? A lot of boottime issues can be caught with pstore enabled at > >> postcore_initcall rather than late_initcall, this backtrace > >> is just one example. Is there any way we could change this? > > > > 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 ;-) -- Steve
