On 13/08/14 05:28, Munyoung Hwang wrote:
Hello Chris,
After appling below patch, I met software deadlock while hmp_idle_pull.
commit 940407d585a1a632086159d19e71bc190a1d07f9 Author: Chris Redpath <chris.redpath@arm.com mailto:chris.redpath@arm.com> Date: Fri May 9 14:36:53 2014 +0100
hmp: Use idle pull to perform forced up-migrationsThe problem is occurred when current task is ksoftirqd and hmp_idle_pull decide to pull a task.
Call stack is as below.
current: ksoftirqd/4
kthread+0xc0 smp_boot_thread_fn+0x118 schedule+0x40 need_resched+0x768 idle_balance+0x180 hmp_idle_pull+0x348 hrtimer_start+0x30 __hrtimer_start_range_ns+0x3a4 raise_softirq_irqoff+0x34 wakeup_softirqd+0x38 wake_up_process+0x34 try_to_wake_up+0x68
I use lsk 14.06 based kernel.
It spins below line on try_to_wake_up. #ifdef CONFIG_SMP /* * If the owning (remote) cpu is still in the middle of schedule() with * this task as prev, wait until its done referencing the task. */ while (p->on_cpu) cpu_relax(); <----------- spinning
Are you aware of this issue? If so, do you have a patch for this?
Thanks, Munyoung.
Hi Munyoung,
This is not something I have seen happen on our platforms, but I would have expected to see it at some point given the report. I wonder if something in our tc2 kernel config prevents this being called at the right time.. would you be able to mail me your config so I can take a look?
In the mean time, can you proceed with your work without using this patch? The benefit is usually pretty small in most cases. I will try to knock up a quick patch to allow this to be turned on and off at runtime and then it could be easily turned off without causing merge issues for later patches while we sort out any issues like this.
Best Regards, Chris