On Mon, 30 Apr 2012, Jiri Kosina wrote: > > Ah, yes. I take it you are talking about tty/vt/keyboard.c. So some > > random keypress during shutdown triggers the event, which eventually > > reaches input_pass_event(). From there on, the trace stays in the > > mentioned driver. First kbd_event() gets called, which takes the lock > > and goes on to, in turn, call kbd_keycode(), k_handler[2]() == > > k_spec(), fn_handler[9]() == fn_hold(), which goes on to call > > stop_tty(). This function comes back to the driver, via con_stop(), as > > vt_kbd_con_stop(), which in turn takes the same lock. So unless the > > teardown of something in hid affects the choices made in the tty > > driver, it appears this is a different problem. Or? > > I just came to the same conclusion a few minutes ago ... i.e. this is > likely unrelated to the patchset and I just triggered it by pure > coincidence on the patched kernel. > > I will keep looking into it a little bit more. Dmitry, any immediate ideas > by any chance? Okay, someone was able to get lockdep complain about this and Alan is apparently on it already: https://lkml.org/lkml/2012/5/1/69 So nothing to be worried about. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
