On Mon, 2011-06-06 at 12:26 +0200, Peter Zijlstra wrote: > On Mon, 2011-06-06 at 12:00 +0200, Arne Jansen wrote: > > As expected this apparently fixes the problem. But are we confident > > enough this is the true source? If it's really that simple, printk > > calling into the scheduler, why am I the only one seeing this? > > Right, so apparently you have contention on console_sem and the up() > actually does a wakeup. I'm still trying to figure out how to do that. On a related note, I'm not quite sure what we need that lockdep_{off,on}() for, I just build and booted a kernel without them and so far life is good. I tried lockdep splats and in-scheduler printk()s (although the latter will still mess up the box if printk()'s up(console_sem) triggers a wakeup for obvious reasons). --- Subject: lockdep, printk: Remove lockdep_off from printk() From: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> Date: Mon Jun 06 13:37:22 CEST 2011 Remove the lockdep_{off,on}() usage from printk() as it appears superfluous, a kernel with this patch on can printk lockdep output just fine. Signed-off-by: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> --- Index: linux-2.6/kernel/printk.c =================================================================== --- linux-2.6.orig/kernel/printk.c +++ linux-2.6/kernel/printk.c @@ -838,7 +838,7 @@ asmlinkage int vprintk(const char *fmt, preempt_disable(); /* This stops the holder of console_sem just where we want him */ - raw_local_irq_save(flags); + local_irq_save(flags); this_cpu = smp_processor_id(); /* @@ -859,7 +859,6 @@ asmlinkage int vprintk(const char *fmt, zap_locks(); } - lockdep_off(); spin_lock(&logbuf_lock); printk_cpu = this_cpu; @@ -956,9 +955,8 @@ asmlinkage int vprintk(const char *fmt, if (console_trylock_for_printk(this_cpu)) console_unlock(); - lockdep_on(); out_restore_irqs: - raw_local_irq_restore(flags); + local_irq_restore(flags); preempt_enable(); return printed_len; -- 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