Re: frequent lockups in 3.18rc4

[Ingo Molnar <mingo@kernel.org>]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> [...]
> 
> That's *especially* true if it turns out that the 3.17 problem 
> you saw was actually a perf bug that has already been fixed and 
> is in stable. We've been looking at kernel/smp.c changes, and 
> looking for x86 IPI or APIC changes, and found some harmlessly 
> (at least on x86) suspicious code and this exercise might be 
> worth it for that reason, but what if it's really just a 
> scheduler regression.
> 
> There's been a *lot* more scheduler changes since 3.17 than the 
> small things we've looked at for x86 entry or IPI handling. And 
> the scheduler changes have been about things like overloaded 
> scheduling groups etc, and I could easily imaging that some bug 
> *there* ends up causing the watchdog process not to schedule.
> 
> Hmm? Scheduler people?

Hm, that's a possibility, yes.

The watchdog threads are pretty simple beasts though, using 
SCHED_FIFO:

 kernel/watchdog.c:      watchdog_set_prio(SCHED_FIFO, MAX_RT_PRIO - 1);

which is typically only affected by less than 10% of scheduler 
changes - but it's entirely possible still.

It might make sense to disable the softlockup detector altogether 
and just see whether trinity finishes/wedges, whether a login 
over the console is still possible - etc.

The softlockup messages in themselves are only analytical, unless 
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1 is used.

Interesting bug.

Thanks,

	Ingo