I have a busy ppc64le KVM box where guests sometimes hit the infamous
"kernel BUG at kernel/smpboot.c:134!" issue during boot:
BUG_ON(td->cpu != smp_processor_id());
Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops
output confirms it:
CPU: 0
Comm: watchdog/130
The issue i
On Sun, Dec 7, 2014 at 7:27 PM, Anton Blanchard wrote:
>
> Since we cannot call set_task_cpu (the task is in a sleeping state),
> just do an explicit set of task_thread_info(p)->cpu.
Scheduler people: is this sufficient and ok?
The __set_task_cpu() function does various other things too:
Hi Linus,
> The __set_task_cpu() function does various other things too:
>
> set_task_rq(p, cpu);
> #ifdef CONFIG_SMP
> /*
> * After ->cpu is set up to a new value, task_rq_lock(p, ...)
> can be
> * successfuly executed on another CPU. We must ensure that
> up
* Anton Blanchard wrote:
> I have a busy ppc64le KVM box where guests sometimes hit the
> infamous "kernel BUG at kernel/smpboot.c:134!" issue during
> boot:
>
> BUG_ON(td->cpu != smp_processor_id());
>
> Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops
> output confir
Hi Ingo,
> So we cannot call set_task_cpu() because in the normal life time
> of a task the ->cpu value gets set on wakeup. So if a task is
> blocked right now, and its affinity changes, it ought to get a
> correct ->cpu selected on wakeup. The affinity mask and the
> current value of ->cpu g
On Mon, 8 Dec 2014 14:27:01 +1100
Anton Blanchard wrote:
> I have a busy ppc64le KVM box where guests sometimes hit the infamous
> "kernel BUG at kernel/smpboot.c:134!" issue during boot:
>
> BUG_ON(td->cpu != smp_processor_id());
>
> Basically a per CPU hotplug thread scheduled on the wrong C
On 12/08/2014 09:54 PM, Steven Rostedt wrote:
> On Mon, 8 Dec 2014 14:27:01 +1100
> Anton Blanchard wrote:
>
>> I have a busy ppc64le KVM box where guests sometimes hit the infamous
>> "kernel BUG at kernel/smpboot.c:134!" issue during boot:
>>
>> BUG_ON(td->cpu != smp_processor_id());
>>
>> Bas
