lkml.org 
[lkml]   [2018]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Crash in msm serial on dragonboard with ftrace bootargs
    From
    Date
    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

    \
     
     \ /
      Last update: 2018-10-16 19:37    [W:3.015 / U:0.680 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site