* Ingo Molnar <mingo@xxxxxxx> wrote: > > * Arne Jansen <lists@xxxxxxxxxxxxxx> wrote: > > > sched.c:934: in function __task_rq_lock > > lockdep_assert_held(&p->pi_lock); > > Oh. Could you remove that line with the patch below - does it result > in a working system? > > Now, this patch alone just removes a debugging check - but i'm not > sure the debugging check is correct - we take the pi_lock in a raw > way - which means it's not lockdep covered. > > So how can lockdep_assert_held() be called on it? Ok, i'm wrong there - it's lockdep covered. I also reviewed all the __task_rq_lock() call sites and each of them has the pi_lock acquired. So unless both Peter and me are blind, the other option would be some sort of memory corruption corrupting the runqueue. But ... that looks so unlikely here, it's clearly heavy printk() and console_sem twiddling that triggers the bug, not any other scheduler activity. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|