On Tue, Dec 18, 2018 at 10:23:02AM +0300, Numan Demirdöğen wrote: > I found that passing the options i8042.reset=1 i8042.dumbkbd=1 i8042.direct=1 > results in the keyboard functioning after resume. However, there is a > long delay before the keyboard or mouse will respond to input on the > lock screen.[1] So the thing is, the mutex works, there's nothing wrong or broken about it (or we'd have known, the kernel would crash and burn). The hand-off stuff fixed at least one known starvation case as well. What it does do, is change timing behaviour. But that is something that is not guaranteed anyway. This all smells like there's some timing dependent behaviour (aka. race condition) in the suspend/keyboard interaction _somewhere_. Now, I know absolutely nothing about either suspend or keyboard stuff, so I really can't help there. The best idea is to add trace_printk() throughout the keyboard suspend/resume code and see if there's a clue to be had there (using remote access to dump the trace buffer after resume, because of lack of keyboard). Obviously that takes someone who knows how that should work ...
