* Ingo Molnar <mingo@xxxxxxx> wrote: > So some essential piece of the puzzle is still missing. Oh. I think the essential piece of the puzzle might be this code in printk(): asmlinkage int vprintk(const char *fmt, va_list args) { ... lockdep_off(); if (console_trylock_for_printk(this_cpu)) console_unlock(); lockdep_on(); ... So while i right now do not see how this (ancient) piece of logic causes trouble, could you try the patch below, does it make the WARN()+lockup go away? Thanks, Ingo diff --git a/kernel/printk.c b/kernel/printk.c index 3518539..1b9d2be 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -859,7 +859,6 @@ asmlinkage int vprintk(const char *fmt, va_list args) zap_locks(); } - lockdep_off(); spin_lock(&logbuf_lock); printk_cpu = this_cpu; @@ -947,7 +946,7 @@ asmlinkage int vprintk(const char *fmt, va_list args) * Try to acquire and then immediately release the * console semaphore. The release will do all the * actual magic (print out buffers, wake up klogd, - * etc). + * etc). * * The console_trylock_for_printk() function * will release 'logbuf_lock' regardless of whether it @@ -956,7 +955,6 @@ asmlinkage int vprintk(const char *fmt, va_list args) if (console_trylock_for_printk(this_cpu)) console_unlock(); - lockdep_on(); out_restore_irqs: raw_local_irq_restore(flags); -- 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