AnsweredAssumed Answered

iMX6 quad plus is freezing in kernel Yocto 4.9.11-1.0.0

Question asked by Ankith Naik on Nov 23, 2018

Hi,

I'm Using iMX6 quad plus Sabre board and have built the Yocto kernel version 4.9.11-1.0.0. In our product we are using QT for GUI and after running QT for about 1 to 2 hours the whole kernel kind of freezes or hangs and the doesn't take any input. I tested the same application with same kernel version in sabre Quad board there also its same case. I'm attaching the log which got generated in such situations.

 

fec 2188000.ethernet eth0: MDIO read timeout
max11801_ts 1-0048: FIFO_RD_AUX_MSB read failed (-110)
max11801_ts 1-0048: FIFO_RD_AUX_MSB read failed (-110)
max11801_ts 1-0048: FIFO_RD_AUX_MSB read failed (-110)
max11801_ts 1-0048: FIFO_RD_AUX_MSB read failed (-110)
max11801_ts 1-0048: FIFO_RD_AUX_MSB read failed (-110)
max11801_ts 1-0048: FIFO_RD_AUX_MSB read failed (-110)
max11801_ts 1-0048: FIFO_RD_AUX_MSB read failed (-110)
max11801_ts 1-0048: FIFO_RD_AUX_MSB read failed (-110)
INFO: rcu_preempt detected stalls on CPUs/tasks:
        (detected by 1, t=2103 jiffies, g=87008, c=87007, q=954)
All QSes seen, last rcu_preempt kthread activity 2101 (448055-445954), jiffies_till_next_fqs=1, root ->qsmask 0x0
swapper/1       R  running task        0     0      1 0x00000000
[<8010eb64>] (unwind_backtrace) from [<8010b180>] (show_stack+0x10/0x14)
[<8010b180>] (show_stack) from [<8017e494>] (rcu_check_callbacks+0x9bc/0x9c8)
[<8017e494>] (rcu_check_callbacks) from [<80181628>] (update_process_times+0x34/0x5c)
[<80181628>] (update_process_times) from [<801924a4>] (tick_sched_timer+0x54/0x98)
[<801924a4>] (tick_sched_timer) from [<80182594>] (__hrtimer_run_queues+0x118/0x1ac)
[<80182594>] (__hrtimer_run_queues) from [<801827f0>] (hrtimer_interrupt+0xa8/0x1f8)
[<801827f0>] (hrtimer_interrupt) from [<8010e49c>] (twd_handler+0x30/0x38)
[<8010e49c>] (twd_handler) from [<80174a70>] (handle_percpu_devid_irq+0x8c/0x144)
[<80174a70>] (handle_percpu_devid_irq) from [<8016ff00>] (generic_handle_irq+0x24/0x34)
[<8016ff00>] (generic_handle_irq) from [<80170428>] (__handle_domain_irq+0x7c/0xec)
[<80170428>] (__handle_domain_irq) from [<801014e8>] (gic_handle_irq+0x48/0x8c)
[<801014e8>] (gic_handle_irq) from [<8010bc8c>] (__irq_svc+0x6c/0xa8)
Exception stack(0xa80a9f68 to 0xa80a9fb0)
9f60:                   00000001 80c27644 00000001 2a892000 03b436d0 00000459
9f80: ab70be28 00000000 03fc6896 00000459 00000000 00000050 29aaaaab a80a9fb8
9fa0: 80166ee8 806e2580 20010013 ffffffff
[<8010bc8c>] (__irq_svc) from [<806e2580>] (cpuidle_enter_state+0x178/0x2a0)
[<806e2580>] (cpuidle_enter_state) from [<80167110>] (cpu_startup_entry+0x148/0x218)
[<80167110>] (cpu_startup_entry) from [<101015cc>] (0x101015cc)
rcu_preempt kthread starved for 2116 jiffies! g87008 c87007 f0x2 RCU_GP_DOING_FQS(4) ->state=0x0
rcu_preempt     R  running task        0     7      2 0x00000000
[<80983a04>] (__schedule) from [<80f0fe40>] (rcu_preempt_state+0x0/0x2c0)

 

 

Any solutions or patch for this kind of issues will be very helpful.

Outcomes