Re: [regression, bisected] Keyboard not responding after resuming from suspend/hibernate

[Peter Zijlstra <peterz@infradead.org>]

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 ...