* Stack trace using ftrace
@ 2015-07-05 11:33 Jungseok Lee
2015-07-06 7:56 ` AKASHI Takahiro
0 siblings, 1 reply; 5+ messages in thread
From: Jungseok Lee @ 2015-07-05 11:33 UTC (permalink / raw)
To: linux-arm-kernel
Greetings,
As playing with ftrace to gather kernel stack data on ARM64 kernel,
I've found out data from /sys/kernel/debug/tracing/stack_trace looks odd.
One of example using 4.1 kernel + dragonboard410c is as follows.
Depth Size Location (50 entries)
----- ---- --------
0) 5256 0 notifier_call_chain+0x30/0x94
1) 5256 0 ftrace_call+0x0/0x4
2) 5256 0 notifier_call_chain+0x2c/0x94
3) 5256 0 raw_notifier_call_chain+0x34/0x44
4) 5256 0 timekeeping_update.constprop.9+0xb8/0x114
5) 5256 0 update_wall_time+0x408/0x6dc
6) 5256 0 tick_do_update_jiffies64+0xd8/0x154
7) 5256 0 tick_sched_do_timer+0x50/0x60
8) 5256 0 tick_sched_timer+0x34/0x90
9) 5256 0 __run_hrtimer+0x60/0x258
10) 5256 0 hrtimer_interrupt+0xe8/0x260
11) 5256 0 arch_timer_handler_virt+0x38/0x48
12) 5256 0 handle_percpu_devid_irq+0x84/0x188
13) 5256 0 generic_handle_irq+0x38/0x54
14) 5256 0 __handle_domain_irq+0x68/0xbc
15) 5256 0 gic_handle_irq+0x38/0x88
16) 5256 0 el1_irq+0x64/0xd8
17) 5256 0 kmem_cache_alloc+0x258/0x294
18) 5256 0 __alloc_skb+0x48/0x180
19) 5256 0 alloc_skb_with_frags+0x74/0x234
20) 5256 0 sock_alloc_send_pskb+0x1d0/0x294
21) 5256 0 sock_alloc_send_skb+0x44/0x54
22) 5256 0 __ip_append_data.isra.40+0x78c/0xb48
23) 5256 0 ip_append_data.part.42+0x98/0xe8
24) 5256 0 ip_append_data+0x68/0x7c
25) 5256 0 icmp_push_reply+0x7c/0x144
26) 5256 0 icmp_send+0x3c0/0x3c8
27) 5256 0 __udp4_lib_rcv+0x5b8/0x684
28) 5256 0 udp_rcv+0x2c/0x3c
29) 5256 0 ip_local_deliver+0xa0/0x224
30) 5256 0 ip_rcv+0x360/0x57c
31) 5256 0 __netif_receive_skb_core+0x4d0/0x80c
32) 5256 0 __netif_receive_skb+0x24/0x84
33) 5256 0 process_backlog+0x9c/0x15c
34) 5256 0 net_rx_action+0x1ec/0x32c
35) 5256 0 __do_softirq+0x114/0x2f0
36) 5256 0 do_softirq+0x60/0x68
37) 5256 0 __local_bh_enable_ip+0xb0/0xd4
38) 5256 0 ip_finish_output+0x1f4/0xabc
39) 5256 0 ip_output+0xf0/0x120
40) 5256 0 ip_local_out_sk+0x44/0x54
41) 5256 0 ip_send_skb+0x24/0xbc
42) 5256 0 udp_send_skb+0x1b4/0x2f4
43) 5256 0 udp_sendmsg+0x2a8/0x7a0
44) 5256 0 inet_sendmsg+0xa0/0xd0
45) 5256 0 sock_sendmsg+0x30/0x78
46) 5256 0 ___sys_sendmsg+0x15c/0x26c
47) 5256 0 __sys_sendmmsg+0x94/0x180
48) 5256 0 SyS_sendmmsg+0x38/0x54
49) 5256 5256 el0_svc_naked+0x20/0x28
I think size *0* does not make sense.
It does not match with Documentation/trace/ftrace.txt.
Am I missing something?
I attach additional information which might be helpful.
1) Kernel configuration
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_TRACER_SNAPSHOT is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
CONFIG_STACK_TRACER=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_PROBE_EVENTS is not set
CONFIG_DYNAMIC_FTRACE=y
# CONFIG_FUNCTION_PROFILER is not set
CONFIG_FTRACE_MCOUNT_RECORD=y
CONFIG_FTRACE_SELFTEST=y
CONFIG_FTRACE_STARTUP_TEST=y
2) Ftrace selftest result
[ 110.791609] Testing all events: OK
[ 110.999956] Testing ftrace filter: OK
Thanks for any advice or help in advance!
Best Regards
Jungseok Lee
^ permalink raw reply [flat|nested] 5+ messages in thread
* Stack trace using ftrace
2015-07-05 11:33 Stack trace using ftrace Jungseok Lee
@ 2015-07-06 7:56 ` AKASHI Takahiro
2015-07-06 12:04 ` Jungseok Lee
0 siblings, 1 reply; 5+ messages in thread
From: AKASHI Takahiro @ 2015-07-06 7:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Thank you for your bug report.
This issue comes from the fact that ftrace, more specifically check_stack(),
goes over immediate values in the stack with each function's (bl instruction's) PC
which is returned by save_stack_trace() while save_stack_trace(), or unwind_frame(),
decrements the saved value of PC in the stack by 4. So mismatching can happen.
We can easily fix the problem by reverting the following commit:
> commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63
> Author: Olof Johansson <olof@lixom.net>
> Date: Fri Feb 14 19:35:15 2014 +0000
>
> ARM64: unwind: Fix PC calculation
But it will also resurrect the original problem.
Another possible fix is to put arm64-specific hack in check_stack(),
but it's also undesirable.
-Takahiro AKASHI
On 07/05/2015 08:33 PM, Jungseok Lee wrote:
> Greetings,
>
> As playing with ftrace to gather kernel stack data on ARM64 kernel,
> I've found out data from /sys/kernel/debug/tracing/stack_trace looks odd.
>
> One of example using 4.1 kernel + dragonboard410c is as follows.
>
> Depth Size Location (50 entries)
> ----- ---- --------
> 0) 5256 0 notifier_call_chain+0x30/0x94
> 1) 5256 0 ftrace_call+0x0/0x4
> 2) 5256 0 notifier_call_chain+0x2c/0x94
> 3) 5256 0 raw_notifier_call_chain+0x34/0x44
> 4) 5256 0 timekeeping_update.constprop.9+0xb8/0x114
> 5) 5256 0 update_wall_time+0x408/0x6dc
> 6) 5256 0 tick_do_update_jiffies64+0xd8/0x154
> 7) 5256 0 tick_sched_do_timer+0x50/0x60
> 8) 5256 0 tick_sched_timer+0x34/0x90
> 9) 5256 0 __run_hrtimer+0x60/0x258
> 10) 5256 0 hrtimer_interrupt+0xe8/0x260
> 11) 5256 0 arch_timer_handler_virt+0x38/0x48
> 12) 5256 0 handle_percpu_devid_irq+0x84/0x188
> 13) 5256 0 generic_handle_irq+0x38/0x54
> 14) 5256 0 __handle_domain_irq+0x68/0xbc
> 15) 5256 0 gic_handle_irq+0x38/0x88
> 16) 5256 0 el1_irq+0x64/0xd8
> 17) 5256 0 kmem_cache_alloc+0x258/0x294
> 18) 5256 0 __alloc_skb+0x48/0x180
> 19) 5256 0 alloc_skb_with_frags+0x74/0x234
> 20) 5256 0 sock_alloc_send_pskb+0x1d0/0x294
> 21) 5256 0 sock_alloc_send_skb+0x44/0x54
> 22) 5256 0 __ip_append_data.isra.40+0x78c/0xb48
> 23) 5256 0 ip_append_data.part.42+0x98/0xe8
> 24) 5256 0 ip_append_data+0x68/0x7c
> 25) 5256 0 icmp_push_reply+0x7c/0x144
> 26) 5256 0 icmp_send+0x3c0/0x3c8
> 27) 5256 0 __udp4_lib_rcv+0x5b8/0x684
> 28) 5256 0 udp_rcv+0x2c/0x3c
> 29) 5256 0 ip_local_deliver+0xa0/0x224
> 30) 5256 0 ip_rcv+0x360/0x57c
> 31) 5256 0 __netif_receive_skb_core+0x4d0/0x80c
> 32) 5256 0 __netif_receive_skb+0x24/0x84
> 33) 5256 0 process_backlog+0x9c/0x15c
> 34) 5256 0 net_rx_action+0x1ec/0x32c
> 35) 5256 0 __do_softirq+0x114/0x2f0
> 36) 5256 0 do_softirq+0x60/0x68
> 37) 5256 0 __local_bh_enable_ip+0xb0/0xd4
> 38) 5256 0 ip_finish_output+0x1f4/0xabc
> 39) 5256 0 ip_output+0xf0/0x120
> 40) 5256 0 ip_local_out_sk+0x44/0x54
> 41) 5256 0 ip_send_skb+0x24/0xbc
> 42) 5256 0 udp_send_skb+0x1b4/0x2f4
> 43) 5256 0 udp_sendmsg+0x2a8/0x7a0
> 44) 5256 0 inet_sendmsg+0xa0/0xd0
> 45) 5256 0 sock_sendmsg+0x30/0x78
> 46) 5256 0 ___sys_sendmsg+0x15c/0x26c
> 47) 5256 0 __sys_sendmmsg+0x94/0x180
> 48) 5256 0 SyS_sendmmsg+0x38/0x54
> 49) 5256 5256 el0_svc_naked+0x20/0x28
>
> I think size *0* does not make sense.
> It does not match with Documentation/trace/ftrace.txt.
>
> Am I missing something?
> I attach additional information which might be helpful.
>
> 1) Kernel configuration
> CONFIG_NOP_TRACER=y
> CONFIG_HAVE_FUNCTION_TRACER=y
> CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
> CONFIG_HAVE_DYNAMIC_FTRACE=y
> CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
> CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
> CONFIG_HAVE_C_RECORDMCOUNT=y
> CONFIG_TRACE_CLOCK=y
> CONFIG_RING_BUFFER=y
> CONFIG_EVENT_TRACING=y
> CONFIG_CONTEXT_SWITCH_TRACER=y
> CONFIG_TRACING=y
> CONFIG_GENERIC_TRACER=y
> CONFIG_TRACING_SUPPORT=y
> CONFIG_FTRACE=y
> CONFIG_FUNCTION_TRACER=y
> CONFIG_FUNCTION_GRAPH_TRACER=y
> # CONFIG_IRQSOFF_TRACER is not set
> # CONFIG_PREEMPT_TRACER is not set
> # CONFIG_SCHED_TRACER is not set
> # CONFIG_FTRACE_SYSCALLS is not set
> # CONFIG_TRACER_SNAPSHOT is not set
> CONFIG_BRANCH_PROFILE_NONE=y
> # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
> # CONFIG_PROFILE_ALL_BRANCHES is not set
> CONFIG_STACK_TRACER=y
> # CONFIG_BLK_DEV_IO_TRACE is not set
> # CONFIG_PROBE_EVENTS is not set
> CONFIG_DYNAMIC_FTRACE=y
> # CONFIG_FUNCTION_PROFILER is not set
> CONFIG_FTRACE_MCOUNT_RECORD=y
> CONFIG_FTRACE_SELFTEST=y
> CONFIG_FTRACE_STARTUP_TEST=y
>
> 2) Ftrace selftest result
> [ 110.791609] Testing all events: OK
> [ 110.999956] Testing ftrace filter: OK
>
> Thanks for any advice or help in advance!
>
> Best Regards
> Jungseok Lee
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Stack trace using ftrace
2015-07-06 7:56 ` AKASHI Takahiro
@ 2015-07-06 12:04 ` Jungseok Lee
2015-07-07 7:59 ` AKASHI Takahiro
0 siblings, 1 reply; 5+ messages in thread
From: Jungseok Lee @ 2015-07-06 12:04 UTC (permalink / raw)
To: linux-arm-kernel
On Jul 6, 2015, at 4:56 PM, AKASHI Takahiro wrote:
> Hi,
Hi,
> Thank you for your bug report.
Thanks for taking care about this topic.
> This issue comes from the fact that ftrace, more specifically check_stack(),
> goes over immediate values in the stack with each function's (bl instruction's) PC
> which is returned by save_stack_trace() while save_stack_trace(), or unwind_frame(),
> decrements the saved value of PC in the stack by 4. So mismatching can happen.
>
> We can easily fix the problem by reverting the following commit:
>
> > commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63
> > Author: Olof Johansson <olof@lixom.net>
> > Date: Fri Feb 14 19:35:15 2014 +0000
> >
> > ARM64: unwind: Fix PC calculation
>
> But it will also resurrect the original problem.
IMHO, a current problem cannot be resolved by reverting the commit.
Please refer to the following data. The result looks much better than before,
but some entries still have 0 sizes.
Depth Size Location (47 entries)
----- ---- --------
0) 4664 240 jiffies_to_timeval+0x1c/0x7c
1) 4424 0 ftrace_graph_call+0x0/0x14
2) 4424 0 jiffies_to_timeval+0x1c/0x7c
3) 4424 0 __acct_update_integrals+0x4c/0xbc
4) 4424 0 acct_account_cputime+0x28/0x34
5) 4424 0 account_system_time+0xb4/0x1e0
6) 4424 32 account_process_tick+0x58/0xa0
7) 4392 48 update_process_times+0x30/0x74
8) 4344 32 tick_sched_handle.isra.15+0x3c/0x7c
9) 4312 48 tick_sched_timer+0x4c/0x90
10) 4264 48 __run_hrtimer+0x64/0x258
11) 4216 64 hrtimer_interrupt+0xec/0x260
12) 4152 128 arch_timer_handler_virt+0x3c/0x48
13) 4024 32 handle_percpu_devid_irq+0x88/0x188
14) 3992 64 generic_handle_irq+0x3c/0x54
15) 3928 32 __handle_domain_irq+0x6c/0xbc
16) 3896 64 gic_handle_irq+0x3c/0x88
17) 3832 336 el1_irq+0x68/0xd8
18) 3496 112 icmp_glue_bits+0x50/0x94
19) 3384 80 __ip_append_data.isra.40+0x894/0xb48
20) 3304 224 ip_append_data.part.42+0x9c/0xe8
21) 3080 112 ip_append_data+0x6c/0x7c
22) 2968 96 icmp_push_reply+0x80/0x144
23) 2872 96 icmp_send+0x3c4/0x3c8
24) 2776 192 __udp4_lib_rcv+0x5bc/0x684
25) 2584 96 udp_rcv+0x30/0x3c
26) 2488 32 ip_local_deliver+0xa4/0x224
27) 2456 48 ip_rcv+0x364/0x57c
28) 2408 64 __netif_receive_skb_core+0x4d4/0x80c
29) 2344 128 __netif_receive_skb+0x28/0x84
30) 2216 32 process_backlog+0xa0/0x15c
31) 2184 80 net_rx_action+0x1f0/0x32c
32) 2104 160 __do_softirq+0x118/0x2f0
33) 1944 128 do_softirq+0x64/0x68
34) 1816 32 __local_bh_enable_ip+0xb4/0xd4
35) 1784 32 ip_finish_output+0x1f8/0xabc
36) 1752 96 ip_output+0xf4/0x120
37) 1656 64 ip_local_out_sk+0x48/0x54
38) 1592 32 ip_send_skb+0x28/0xbc
39) 1560 48 udp_send_skb+0x1b8/0x2f4
40) 1512 80 udp_sendmsg+0x2ac/0x7a0
41) 1432 272 inet_sendmsg+0xa4/0xd0
42) 1160 48 sock_sendmsg+0x34/0x78
43) 1112 32 ___sys_sendmsg+0x160/0x26c
44) 1080 400 __sys_sendmmsg+0x98/0x180
45) 680 320 SyS_sendmmsg+0x3c/0x54
46) 360 360 el0_svc_naked+0x24/0x28
Best Regards
Jungseok Lee
^ permalink raw reply [flat|nested] 5+ messages in thread
* Stack trace using ftrace
2015-07-06 12:04 ` Jungseok Lee
@ 2015-07-07 7:59 ` AKASHI Takahiro
2015-07-07 13:49 ` Jungseok Lee
0 siblings, 1 reply; 5+ messages in thread
From: AKASHI Takahiro @ 2015-07-07 7:59 UTC (permalink / raw)
To: linux-arm-kernel
On 07/06/2015 09:04 PM, Jungseok Lee wrote:
> On Jul 6, 2015, at 4:56 PM, AKASHI Takahiro wrote:
>> Hi,
>
> Hi,
>
>> Thank you for your bug report.
>
> Thanks for taking care about this topic.
>
>> This issue comes from the fact that ftrace, more specifically check_stack(),
>> goes over immediate values in the stack with each function's (bl instruction's) PC
>> which is returned by save_stack_trace() while save_stack_trace(), or unwind_frame(),
>> decrements the saved value of PC in the stack by 4. So mismatching can happen.
>>
>> We can easily fix the problem by reverting the following commit:
>>
>>> commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63
>>> Author: Olof Johansson <olof@lixom.net>
>>> Date: Fri Feb 14 19:35:15 2014 +0000
>>>
>>> ARM64: unwind: Fix PC calculation
>>
>> But it will also resurrect the original problem.
>
> IMHO, a current problem cannot be resolved by reverting the commit.
> Please refer to the following data. The result looks much better than before,
> but some entries still have 0 sizes.
Sorry for that.
There seem to be several problems.
The value in 'size' field should go one line up,
for example, 32 for arch_timer_handler and 64 for
handle_percpu_devid_irq.
I'm now looking into those issues.
-Takahiro AKASHI
> Depth Size Location (47 entries)
> ----- ---- --------
> 0) 4664 240 jiffies_to_timeval+0x1c/0x7c
> 1) 4424 0 ftrace_graph_call+0x0/0x14
> 2) 4424 0 jiffies_to_timeval+0x1c/0x7c
> 3) 4424 0 __acct_update_integrals+0x4c/0xbc
> 4) 4424 0 acct_account_cputime+0x28/0x34
> 5) 4424 0 account_system_time+0xb4/0x1e0
> 6) 4424 32 account_process_tick+0x58/0xa0
> 7) 4392 48 update_process_times+0x30/0x74
> 8) 4344 32 tick_sched_handle.isra.15+0x3c/0x7c
> 9) 4312 48 tick_sched_timer+0x4c/0x90
> 10) 4264 48 __run_hrtimer+0x64/0x258
> 11) 4216 64 hrtimer_interrupt+0xec/0x260
> 12) 4152 128 arch_timer_handler_virt+0x3c/0x48
> 13) 4024 32 handle_percpu_devid_irq+0x88/0x188
> 14) 3992 64 generic_handle_irq+0x3c/0x54
> 15) 3928 32 __handle_domain_irq+0x6c/0xbc
> 16) 3896 64 gic_handle_irq+0x3c/0x88
> 17) 3832 336 el1_irq+0x68/0xd8
> 18) 3496 112 icmp_glue_bits+0x50/0x94
> 19) 3384 80 __ip_append_data.isra.40+0x894/0xb48
> 20) 3304 224 ip_append_data.part.42+0x9c/0xe8
> 21) 3080 112 ip_append_data+0x6c/0x7c
> 22) 2968 96 icmp_push_reply+0x80/0x144
> 23) 2872 96 icmp_send+0x3c4/0x3c8
> 24) 2776 192 __udp4_lib_rcv+0x5bc/0x684
> 25) 2584 96 udp_rcv+0x30/0x3c
> 26) 2488 32 ip_local_deliver+0xa4/0x224
> 27) 2456 48 ip_rcv+0x364/0x57c
> 28) 2408 64 __netif_receive_skb_core+0x4d4/0x80c
> 29) 2344 128 __netif_receive_skb+0x28/0x84
> 30) 2216 32 process_backlog+0xa0/0x15c
> 31) 2184 80 net_rx_action+0x1f0/0x32c
> 32) 2104 160 __do_softirq+0x118/0x2f0
> 33) 1944 128 do_softirq+0x64/0x68
> 34) 1816 32 __local_bh_enable_ip+0xb4/0xd4
> 35) 1784 32 ip_finish_output+0x1f8/0xabc
> 36) 1752 96 ip_output+0xf4/0x120
> 37) 1656 64 ip_local_out_sk+0x48/0x54
> 38) 1592 32 ip_send_skb+0x28/0xbc
> 39) 1560 48 udp_send_skb+0x1b8/0x2f4
> 40) 1512 80 udp_sendmsg+0x2ac/0x7a0
> 41) 1432 272 inet_sendmsg+0xa4/0xd0
> 42) 1160 48 sock_sendmsg+0x34/0x78
> 43) 1112 32 ___sys_sendmsg+0x160/0x26c
> 44) 1080 400 __sys_sendmmsg+0x98/0x180
> 45) 680 320 SyS_sendmmsg+0x3c/0x54
> 46) 360 360 el0_svc_naked+0x24/0x28
>
> Best Regards
> Jungseok Lee
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Stack trace using ftrace
2015-07-07 7:59 ` AKASHI Takahiro
@ 2015-07-07 13:49 ` Jungseok Lee
0 siblings, 0 replies; 5+ messages in thread
From: Jungseok Lee @ 2015-07-07 13:49 UTC (permalink / raw)
To: linux-arm-kernel
On Jul 7, 2015, at 4:59 PM, AKASHI Takahiro wrote:
> On 07/06/2015 09:04 PM, Jungseok Lee wrote:
>> On Jul 6, 2015, at 4:56 PM, AKASHI Takahiro wrote:
>>> Hi,
>>
>> Hi,
>>
>>> Thank you for your bug report.
>>
>> Thanks for taking care about this topic.
>>
>>> This issue comes from the fact that ftrace, more specifically check_stack(),
>>> goes over immediate values in the stack with each function's (bl instruction's) PC
>>> which is returned by save_stack_trace() while save_stack_trace(), or unwind_frame(),
>>> decrements the saved value of PC in the stack by 4. So mismatching can happen.
>>>
>>> We can easily fix the problem by reverting the following commit:
>>>
>>>> commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63
>>>> Author: Olof Johansson <olof@lixom.net>
>>>> Date: Fri Feb 14 19:35:15 2014 +0000
>>>>
>>>> ARM64: unwind: Fix PC calculation
>>>
>>> But it will also resurrect the original problem.
>>
>> IMHO, a current problem cannot be resolved by reverting the commit.
>> Please refer to the following data. The result looks much better than before,
>> but some entries still have 0 sizes.
>
> Sorry for that.
It's okay.
> There seem to be several problems.
> The value in 'size' field should go one line up,
> for example, 32 for arch_timer_handler and 64 for
> handle_percpu_devid_irq.
>
> I'm now looking into those issues.
I can support a test with dragonboard410c. Please let me know if necessary.
Thanks again!
Best Regards
Jungseok Lee
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-07-07 13:49 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-07-05 11:33 Stack trace using ftrace Jungseok Lee
2015-07-06 7:56 ` AKASHI Takahiro
2015-07-06 12:04 ` Jungseok Lee
2015-07-07 7:59 ` AKASHI Takahiro
2015-07-07 13:49 ` Jungseok Lee
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).