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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <ed648cc5-0748-8bcc-5ebb-ce6dbc7d4fee@linaro.org>
Date:   Thu, 15 Nov 2018 10:53:24 +0000
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>,
        Steven Rostedt <rostedt@...dmis.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 15/11/18 10:33, Sai Prakash Ranjan wrote:
> On 11/13/2018 3:14 PM, Srinivas Kandagatla wrote:
>> Hi Sai,
>>
>>
>>
>> On 25/10/18 15:36, saiprakash.ranjan@...eaurora.org wrote:
>>> "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.
>>
>> Its Interesting that my old email conversations with SBoyd show that I 
>> have investigated this issue in early 2016!
>>
>> My analysis so far:
>>
>> This reason for such behavior is due the common iface clock
>> (GCC_BLSP1_AHB_CLK) across multiple drivers(serial ports, bam dma
>> and other low speed devices).
>> The code flow in DB410C is bit different, as the uart0 is first
>> attempted to set as console and then uart1, this ordering triggers
>> pm state change uart_change_pm(state, UART_PM_STATE_OFF) from serial
>> core while setting up uart0, this would go and disable all the
>> clocks for uart0.
>> As uart1 is not setup Yet, and earlycon is still active, any
>> attempts by earlycon to write to registers would trigger a system
>> reboot as the clock was just disabled by uart0 change_pm code.
>>
>> This can even be triggered with any drivers like spi which uses same
>> clock I guess.
>>
>> Hope it helps,
>>
>> Either earlycon needs to reference the clocks or those clocks needs to
>> be marked always-on (but only with earlycon).
>>
>>>
>>> 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?
>> No, this is not the case with DB410c. DB820c has added restrictions in 
>> TZ, I think new booloaders should have solved this issue.
>>
>>
> 
> Hi Srinivas,
> 
> Thanks a lot for pointing out the cause of crash.
> I just tried setting GCC_BLSP1_AHB_CLK with flag CLK_IS_CRITICAL and the
> crash disappears.
> 
> But I suppose setting CLK_IS_CRITICAL is not the solution?
> 

Yes, this is not the solution, but it proves that the hand-off between 
booloaders and kernel is the issue.

In general there is wider issue with resources hand-off between 
bootloader and kernel.

There has been some proposal in the past by Viresh for a new framework 
called boot-constriants (https://lkml.org/lkml/2017/12/14/440) which am 
not sure if its still actively looked at. But something similar should 
be the way to address such issues.

--srini




> Thanks,
> Sai