> Bingo, that was the problem in my setup: as the patch was applied
> through a script with others, I had missed the error message about the
> conflict (I have also another conflict which can be safely ignored so
> the new one did not catch my eye)... So the patch was only
> half-applied, and the final code is broken.
> How did you solve the conflict (I am not a scheduler expert)? I can
> retry running the patched kernel with your resolution, to check if
> everything is ok.
After looking a bit more, the conflict resolution seemed straighforward,
so I gave it a go. The attached version booted fine, so the initial
problem was purely PEBCAK... Sorry for the noise!
--
Damien
--- a/kernel/sched/fair.c 2013-02-06 20:49:17.447613049 +0100
+++ b/kernel/sched/fair.c 2013-02-13 20:52:37.409507417 +0100
@@ -5060,6 +5060,10 @@
ld_moved = 0;
lb_iterations = 1;
clock_updated = 0;
+
+ env.src_cpu = busiest->cpu;
+ env.src_rq = busiest;
+
if (busiest->nr_running > 1) {
/*
* Attempt to move tasks. If find_busiest_group has found
@@ -5068,8 +5072,6 @@
* correctly treated as an imbalance.
*/
env.flags |= LBF_ALL_PINNED;
- env.src_cpu = busiest->cpu;
- env.src_rq = busiest;
env.loop_max = min(sysctl_sched_nr_migrate, busiest->nr_running);
update_h_load(env.src_cpu);
