linux-kernel - Re: Crash in msm serial on dragonboard with ftrace bootargs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 25 Oct 2018 20:06:39 +0530
From:   saiprakash.ranjan@...eaurora.org
To:     Steven Rostedt <rostedt@...dmis.org>,
        srinivas.kandagatla@...aro.org, Stephen Boyd <sboyd@...nel.org>
Cc:     Joel Fernandes <joel@...lfernandes.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Andy Gross <andy.gross@...aro.org>,
        David Brown <david.brown@...aro.org>,
        Jiri Slaby <jslaby@...e.com>,
        Kees Cook <keescook@...omium.org>,
        Geliang Tang <geliangtang@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Pramod Gurav <gpramod@...eaurora.org>,
        linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
        linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Vivek Gautam <vivek.gautam@...eaurora.org>,
        Sibi Sankar <sibis@...eaurora.org>
Subject: Re: Crash in msm serial on dragonboard with ftrace bootargs

On 10/19/2018 8:42 PM, Steven Rostedt wrote:
> On Fri, 19 Oct 2018 20:18:19 +0530
> Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org> wrote:
> 
> 
>>> You said that if you add 'ftrace_filter=msm_read' to the command 
>>> line,
>>> it still crashes?
>>> 
>>> So only tracing that function we have an issue, right?
>>> 
>> 
>> Tracing msm_read does cause the crash, but that is not the only one
>> causing the crash because even after "ftrace_notrace=msm_read" the 
>> board
>> crashes which is why I suspect msm earlycon and not ftrace.
> 
> I'm saying there's a combination of the two. Because when ftrace is not
> involved, early con doesn't crash.
> 
> I would focus on why earlycon crashes when only msm_read is traced.
> That should help narrow down the cause.
> 
> What we know is:
> 
> 	earlycon -> boots
> 
> 	ftrace=function -> boots
> 
>   	earlycon ftrace=function ftrace_filter=msm_read -> crashes
> 
> If we remove the "ftrace=function ftrace_filter=msm_read" it boots
> fine, and I'm assuming that if we just remove earlycon (keeping the
> ftrace_filter), it also boots too.
> 
> Thus, ftrace tracing msm_read is causing earlycon to do something that
> triggers the crash.
> 

Hi,

Sorry for late response on this, was running out of debug options
;-)

Finally after bisecting (which I should have done earlier) this issue
till 4.4 kernel where I don't see the crash,  I could see that
dma node in "apq8016-sbc.dtsi" is somehow causing the crash.

                 dma@...4000 {
                          status = "okay";    <--- This one
                  };

                  serial@...f000 {
                          label = "LS-UART0";
                          status = "okay";
                          pinctrl-names = "default", "sleep";
                          pinctrl-0 = <&blsp1_uart1_default>;
                          pinctrl-1 = <&blsp1_uart1_sleep>;
                  };

                  serial@...0000 {
                          label = "LS-UART1";
                          status = "okay";
                          pinctrl-names = "default", "sleep";
                          pinctrl-0 = <&blsp1_uart2_default>;
                          pinctrl-1 = <&blsp1_uart2_sleep>;
                  };

"If I disable dma node and LS-UART0, then I don't see any crash and
ftrace also works fine"

And one more observation is that even without ftrace cmdline, if I use
earlycon and disable dma, I face the same crash.

So basically this seems to be some kind of earlycon and dma issue and
not ftrace(I can be wrong).

So adding Srinivas for more info on this dma node.

Also just for a note: apq8096-db820c.dtsi shows UART0 is disabled 
because
bootloader does not allow access to it. Could this also be the case for 
db410c?

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation