linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Numan Demirdöğen" <if.gnu.linux@gmail.com>
To: linux-pm@vger.kernel.org
Cc: rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz,
	guido.aulisi@gmail.com
Subject: [regression, bisected] Keyboard not responding after resuming from suspend/hibernate
Date: Tue, 25 Jun 2019 13:54:20 +0000	[thread overview]
Message-ID: <20190625135412.78d4e4c3@numan> (raw)

If laptop is put to suspend or hibernate by closing lid, via power
manager or by using any other method and then it is resumed/waked up,
keyboard is not responding but mouse or trackball can be used. Although
I can wake laptop up by keyboard, after that I am stuck at the password
prompt. This bug is present ever since using 4.10-rc1 kernel and mostly
on Sony laptops. The last working kernel version is 4.9.0-rc2.

git bisect points 9d659ae14b545c4296e812c70493bfdc999b5c1c 
as the first bad commit[1].

I tried some kernel parameters related to i8042 driver:
i8042.debug=1 i8042.reset=1	keyboard not working
i8042.debug=1 i8042.kbdreset=1	keyboard not working
i8042.debug=1 i8042.nomux=1	keyboard not working
i8042.debug=1 i8042.noaux=1	keyboard working, but touchpad not
working

A user reported that on some rare occasions, keyboard responded to key
press but it remained pressed forever even if stopped pressing it. And
another user reported that passing the options i8042.reset=1
i8042.dumbkbd=1 i8042.direct=1 resulted in the keyboard functioning
after resume. However, there was a long delay before the keyboard or
mouse responded to input on the lock screen.

This one line patch, which can be a hint, from Takashi Iwai essentially
reverts the commit 9d659ae14b545 mentioned in the above and keyboard is
working as expected after resuming from suspend/hibernate, if this
patch is applied. 

--- 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
 
- The first bug report on bugzilla.kernel.org[2].
- LKML thread[3]
- Another report on OpenSUSE bugzilla[4]

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=9d659ae14b545c4296e812c70493bfdc999b5c1c
[2] https://bugzilla.kernel.org/show_bug.cgi?id=195471
[3] https://lkml.org/lkml/2018/8/31/707
[4]  https://bugzilla.opensuse.org/show_bug.cgi?id=1114588

                 reply	other threads:[~2019-06-25 13:54 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190625135412.78d4e4c3@numan \
    --to=if.gnu.linux@gmail.com \
    --cc=guido.aulisi@gmail.com \
    --cc=len.brown@intel.com \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).