* Arne Jansen <lists@xxxxxxxxxxxxxx> wrote: > From the timing I see I'd guess it has something to do with the > scheduler kicking in during printk. I'm neither familiar with the > printk code nor with the scheduler. Yeah, that's the well-known wake-up of klogd: void console_unlock(void) { ... up(&console_sem); actually ... that's not the klogd wake-up at all (!). I so suck today at bug analysis :-) It's the console lock()/unlock() sequence, and guess what does it: drivers/tty/tty_io.c: console_lock(); drivers/tty/vt/selection.c: console_lock(); and the vt.c code in a dozen places. So maybe it's some sort of tty related memory corruption that was made *visible* via the extra assert that the scheduler is doing? The pi_list is embedded in task struct. This would explain why only printk() triggers it and other wakeup patterns not. Now, i don't really like this theory either. Why is there no other type of corruption? And exactly why did only the task_struct::pi_lock field get corrupted while nearby fields not? Also, none of the fields near pi_lock are even remotely tty related. 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