Hi Vincent, On 2018-04-12 13:15:19 +0200, Niklas Söderlund wrote: > Hi Vincent, > > Thanks for your feedback. > > On 2018-04-12 12:33:27 +0200, Vincent Guittot wrote: > > Hi Niklas, > > > > On 12 April 2018 at 11:18, Niklas Söderlund > > <niklas.soderl...@ragnatech.se> wrote: > > > Hi Vincent, > > > > > > I have observed issues running on linus/master from a few days back [1]. > > > I'm running on a Renesas Koelsch board (arm32) and I can trigger a issue > > > by X forwarding the v4l2 test application qv4l2 over ssh and moving the > > > courser around in the GUI (best test case description award...). I'm > > > sorry about the really bad way I trigger this but I can't do it in any > > > other way, I'm happy to try other methods if you got some ideas. The > > > symptom of the issue is a complete hang of the system for more then 30 > > > seconds and then this information is printed in the console: > > > > Heiner (edded cc) also reported similar problem with his platform: a > > dual core celeron > > > > Do you confirm that your platform is a dual cortex-A15 ? At least that > > what I have seen on web > > This would confirm that dual system is a key point. > > I can confirm that my platform is a dual core.
I tested another dual core system today Renesas M3-W ARM64 system and I can observe the same lockups-on that system if it helps you understand the problem. It seems to be much harder to trigger the issue on this system for some reason. Hitting return in a ssh session don't seem to produce the lockup while starting a GUI using X forwarding over ssh it's possible. [ 392.306441] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 392.312201] (detected by 0, t=19366 jiffies, g=7177, c=7176, q=35) [ 392.318555] All QSes seen, last rcu_preempt kthread activity 19368 (4294990375-4294971007), jiffies_till_next_fqs=1, root ->qsmask 0x0 [ 392.330758] swapper/0 R running task 0 0 0 0x00000022 [ 392.337883] Call trace: [ 392.340365] dump_backtrace+0x0/0x1c8 [ 392.344065] show_stack+0x14/0x20 [ 392.347416] sched_show_task+0x224/0x2e8 [ 392.351377] rcu_check_callbacks+0x8ac/0x8b0 [ 392.355686] update_process_times+0x2c/0x58 [ 392.359908] tick_sched_handle.isra.5+0x30/0x50 [ 392.364479] tick_sched_timer+0x40/0x90 [ 392.368351] __hrtimer_run_queues+0xfc/0x208 [ 392.372659] hrtimer_interrupt+0xd4/0x258 [ 392.376710] arch_timer_handler_virt+0x28/0x48 [ 392.381194] handle_percpu_devid_irq+0x80/0x138 [ 392.385767] generic_handle_irq+0x28/0x40 [ 392.389813] __handle_domain_irq+0x5c/0xb8 [ 392.393946] gic_handle_irq+0x58/0xa8 [ 392.397640] el1_irq+0xb4/0x130 [ 392.400810] arch_cpu_idle+0x14/0x20 [ 392.404422] default_idle_call+0x1c/0x38 [ 392.408381] do_idle+0x17c/0x1f8 [ 392.411640] cpu_startup_entry+0x20/0x28 [ 392.415598] rest_init+0x24c/0x260 [ 392.419037] start_kernel+0x3e8/0x414 I was running the same tests on another ARM64 platform earlier using the same build which have more then two cores and there I could not observe this issue. -- Regards, Niklas Söderlund
