Re: Crash in msm serial on dragonboard with ftrace bootargs

[Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>]

On 10/19/2018 9:47 AM, Joel Fernandes wrote:
> On Thu, Oct 18, 2018 at 09:17:06AM -0400, Steven Rostedt wrote:
>> On Thu, 18 Oct 2018 10:51:18 +0530
>> Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> wrote:
>>
>>>> So something else is causing an issue besides just msm_read.
>>>>
>>>> Can you do an objdump -dr of the entire vmlinux binary and gzip it and
>>>> post it somewhere. Not sure if it would be too big to email. You could
>>>> try sending it to me privately. I'd like to see the binary that you are
>>>> using.
>>>>    
>>>
>>> I have sent the objdump and dot config to you privately.
>>
>> Thanks. I don't see anything that pops out, but then again, my arm asm
>> foo is very rusty (it has been literally decades since I did any arm
>> asm). I wonder if it could simply be a timing issue?
>>
>> ffff0000086eb538 <msm_read.isra.1>:
>> ffff0000086eb538:       a9be7bfd        stp     x29, x30, [sp,#-32]!
>> ffff0000086eb53c:       910003fd        mov     x29, sp
>> ffff0000086eb540:       a90153f3        stp     x19, x20, [sp,#16]
>> ffff0000086eb544:       aa0003f4        mov     x20, x0
>> ffff0000086eb548:       2a0103f3        mov     w19, w1
>> ffff0000086eb54c:       aa1e03e0        mov     x0, x30
>> ffff0000086eb550:       97e6bae4        bl      ffff00000809a0e0 <_mcount>
>>
>> The above is changed to nop on boot, but then to:
>>
>> 	bl ftrace_caller
>>
>> When ftrace is enabled.
>>
>> ffff0000086eb554:       8b334280        add     x0, x20, w19, uxtw
>> ffff0000086eb558:       b9400000        ldr     w0, [x0]
>> ffff0000086eb55c:       a94153f3        ldp     x19, x20, [sp,#16]
>> ffff0000086eb560:       a8c27bfd        ldp     x29, x30, [sp],#32
>> ffff0000086eb564:       d65f03c0        ret
>>
>>
>>
>> ffff00000809a0e4 <ftrace_caller>:
>> ffff00000809a0e4:       a9bf7bfd        stp     x29, x30, [sp,#-16]!
>> ffff00000809a0e8:       910003fd        mov     x29, sp
>> ffff00000809a0ec:       d10013c0        sub     x0, x30, #0x4
>> ffff00000809a0f0:       f94003a1        ldr     x1, [x29]
>> ffff00000809a0f4:       f9400421        ldr     x1, [x1,#8]
>> ffff00000809a0f8:       d1001021        sub     x1, x1, #0x4
>>
>> ffff00000809a0fc <ftrace_call>:
>> ffff00000809a0fc:       d503201f        nop
>>
>> The above nop gets patched to:
>>
>> 	bl ftrace_ops_no_ops
>>
>> Which will iterate through all the registered functions.
>>
>>
>> ffff00000809a100 <ftrace_graph_call>:
>> ffff00000809a100:       d503201f        nop
>>
>> The above only gets set when function graph tracer is enabled, which it
>> is not in this case.
>>
>> ffff00000809a104:       a8c17bfd        ldp     x29, x30, [sp],#16
>> ffff00000809a108:       d65f03c0        ret
>>
>>
>> Anyone see any problems here?
> 
> This seems sane to me, he says in the other thread that he put 'notrace' to
> the msm serial functions (which AIUI should prevent ftrace instrumentation)
> and he still sees the issue.
> 

Yes I did add notrace to all functions in msm serial and checked the 
objdump to make sure that those were not instrumented, and yet the 
target crashed. This doesnt seem like an issue with ftrace but rather 
with msm early con.

Thanks,
Sai

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