Re: [GIT PULL] scheduler changes for v4.3

Ingo Molnar
2015-09-01T08:56:33Z

* Markus Trippelsdorf <markus@trippelsdorf.de> wrote:

> On 2015.09.01 at 10:38 +0200, Ingo Molnar wrote:
> >
> > * Markus Trippelsdorf <markus@trippelsdorf.de> wrote:
> >
> > > Well, git show a1d8561172f369ba56d636df49a6b4d6d77e2123 :
> > >
> > > commit a1d8561172f369ba56d636df49a6b4d6d77e2123
> > > Merge: 3959df1dfb95 ff277d4250fe
> > > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > > Date: Mon Aug 31 20:26:22 2015 -0700
> >
> > > diff --cc kernel/cpu.c
> > > index 3c91a3fdfce5,664ce5299334..82cf9dff4295
> > > --- a/kernel/cpu.c
> > > +++ b/kernel/cpu.c
> > > @@@ -394,15 -392,10 +394,15 @@@ static int _cpu_down(unsigned int cpu,
> > > smpboot_park_threads(cpu);
> > >
> > > /*
> > > - * So now all preempt/rcu users must observe !cpu_active().
> > > + * Prevent irq alloc/free while the dying cpu reorganizes the
> > > + * interrupt affinities.
> > > */
> > > + irq_lock_sparse();
> > >
> > > + /*
> > > + * So now all preempt/rcu users must observe !cpu_active().
> > > + */
> > > - err = __stop_machine(take_cpu_down, &tcd_param, cpumask_of(cpu));
> > > + err = stop_machine(take_cpu_down, &tcd_param, cpumask_of(cpu));
> > > if (err) {
> > > /* CPU didn't die: tell everyone. Can't complain. */
> > > cpu_notify_nofail(CPU_DOWN_FAILED | mod, hcpu);
> >
> > So the irq_lock_sparse() change is from a commit that got merged in the last merge
> > window, which is part of v4.2:
> >
> > ce0d3c0a6fb1 ("genirq: Revert sparse irq locking around __cpu_up() and move it to x86 for now")
> >
> > Could you please post the patch against Linus's latest that you have tested on
> > your system to make it boot fine?
> >
> > The one you posted cannot possibly build, because access to __stop_machine() is
> > gone from cpu.c:
>
> As I wrote in my other reply. The boot failure is nondeterministic (boot
> succeeds roughly every sixth time). So the bisection and the patch is
> just bogus (,but the boot failure is real).
>
> Sorry.

No problem. Please let us know if any of these commits does turn out to be the
culprit. (Which is always a possibility.)

Thanks,

Ingo