lkml.org 
[lkml]   [2018]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")
On 13 April 2018 at 22:38, Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
> 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.soderlund@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.

Thanks for the test. That's confirm, it's only happen on dual core

>
> [ 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

\
 
 \ /
  Last update: 2018-04-14 13:27    [W:0.112 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site