On 29 March 2018 at 19:40, Heiner Kallweit <hkallwe...@gmail.com> wrote: > Am 29.03.2018 um 09:41 schrieb Vincent Guittot:
>> >> I'm finally not so sure that i have the right set up to reproduce the >> problem as I haven't been able to reproduce it since. >> >> Heiner, >> >> How fast the problem happens on your board ? >> Are you doing anything specific on the console that trigger the problem ? >> > Hi Vincent, > > the lag when working on the console is constantly there, the "rcu_preempt > detected stalls" happens after several hours (so far always within 24h) > w/o any triggering event I would be aware of. It occured also when the > system was idle at that point in time. Ok, so I don't have the problem on my hikey as the console never lag on my setup. Can you send me the config of your kernel ? I'd like to check if you have enable something that could trigger such problem Thanks, Vincent > > Rgds, Heiner > >> Regards, >> Vincent >> >>>> >>>>>>> Bisecting the issue resulted in: >>>>>>> >>>>>>> 31e77c93e432dec79c7d90b888bbfc3652592741 is the first bad commit >>>>>>> commit 31e77c93e432dec79c7d90b888bbfc3652592741 >>>>>>> Author: Vincent Guittot <vincent.guit...@linaro.org> >>>>>>> Date: Wed Feb 14 16:26:46 2018 +0100 >>>>>>> >>>>>>> sched/fair: Update blocked load when newly idle >>>>>>> >>>>>>> When NEWLY_IDLE load balance is not triggered, we might need to >>>>>>> update the >>>>>>> blocked load anyway. We can kick an ilb so an idle CPU will take >>>>>>> care of >>>>>>> updating blocked load or we can try to update them locally before >>>>>>> entering >>>>>>> idle. In the latter case, we reuse part of the nohz_idle_balance. >>>>>>> >>>>>>> After reversing this commit at least the issue with the freezing console >>>>>>> is gone. The second one appeared only sporadically, I still have to see >>>>>>> whether it pops up again. >>>> >>>> >>>> [...] >>>> >> >
