Sun, 2 Dec 2018 23:28:09 +0100 tarihinde
Pavel Machek [off-list ref] yazdı:

On Fri 2018-11-30 15:44:55, Numan Demirdöğen wrote:

quoted

Sun, 28 Oct 2018 22:06:54 +0300 tarihinde
Numan Demirdöğen [off-list ref] yazdı:
  

quoted

Thu, 25 Oct 2018 09:49:03 +0200 tarihinde
Pavel Machek [off-list ref] yazdı:
 

quoted

Hi!

Here's problem bisected down to:

commit 9d659ae14b545c4296e812c70493bfdc999b5c1c
Author: Peter Zijlstra [off-list ref]
Date:   Tue Aug 23 14:40:16 2016 +0200

    locking/mutex: Add lock handoff to avoid starvation

    Implement lock handoff to avoid lock starvation.

Numan, I assume revert of that patch on the 4.18 kernel still
makes it work?
    

Unfortunately, I could not revert
9d659ae14b545c4296e812c70493bfdc999b5c1c on kernels from 4.18.16 to
4.10-rc1 because there were too much conflicts, which I could not
solve as an "average Joe". I tried
a3ea3d9b865c2a8f7fe455c7fa26db4b6fd066e3 which is parent of
9d659ae14b545c4296e812c70493bfdc999b5c1c and succeeded to compile
kernel.

git checkout a3ea3d9b865c2a8f7fe455c7fa26db4b6fd066e3

Then, I compiled kernel and rebooted with it. I tried a couples of
times suspending and resuming, all of the time keyboard worked as
expected.
 

With this one line patch from Takashi Iwai, keyboard is working as
expected after resuming from suspend/hibernate.

--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c

@@ -59,7 +59,7 @@ EXPORT_SYMBOL(__mutex_init);
  * Bit2 indicates handoff has been done and we're waiting for

pickup. */
 #define MUTEX_FLAG_WAITERS	0x01
-#define MUTEX_FLAG_HANDOFF	0x02
+#define MUTEX_FLAG_HANDOFF	0x00
 #define MUTEX_FLAG_PICKUP	0x04
 
 #define MUTEX_FLAGS		0x07


Thanks in advance and regards,  

Ok. So it is a regression, and you can ask Linus to apply this
.. but... that's kind of heavy solution. Peter, do you have any other
ideas?

								Pavel

Hi,

I did not mention the one line patch from Takashi Iwai as a means of fix
but as a hint. Sorry for misunderstanding.

Here is a another hint from another user:

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]

[1] https://bugzilla.kernel.org/show_bug.cgi?id=195471#c39

-- 
Numan Demirdöğen