Bug 1114588 - Keyboard Doesn't Work after resuming from sleep.
Keyboard Doesn't Work after resuming from sleep.
Status: RESOLVED NORESPONSE
: 1134807 (view as bug list)
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Kernel
Leap 15.0
x86-64 SUSE Other
: P3 - Medium : Major (vote)
: Leap 15.0
Assigned To: openSUSE Kernel Bugs
E-mail List
:
Depends on:
Blocks: 1134807
  Show dependency treegraph
 
Reported: 2018-11-04 09:59 UTC by Aman Vaishya
Modified: 2021-12-31 14:43 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Files, containing the output of the commands, as asked (456.52 KB, application/zip)
2018-11-06 12:56 UTC, Aman Vaishya
Details
attached file after passing i8042.debug=1 (117.62 KB, application/zip)
2018-11-11 11:21 UTC, Aman Vaishya
Details
Dmesg output after suspend with parameter i8042.debug=1 (495.05 KB, text/plain)
2018-11-20 11:06 UTC, Aman Vaishya
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aman Vaishya 2018-11-04 09:59:19 UTC
Sony Vaio SVF15218, Keyboard doesn't work after resume from sleep.
The output of lspci is below.


*00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4)
00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM76 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C216 Chipset Family SMBus Controller (rev 04)
01:00.0 3D controller: NVIDIA Corporation GK208M [GeForce GT 740M] (rev a1)
07:00.0 Network controller: Broadcom Limited BCM43142 802.11b/g/n (rev 01)
08:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5209 PCI Express Card Reader (rev 01)
0e:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)*

The kernel that I am using is *4.12.14-lp150.12.22-default*
However the issue is there since I had upgraded to leap 15.0
Comment 1 Takashi Iwai 2018-11-06 11:45:04 UTC
Could you give the output of hwinfo, and the kernel messages (dmesg output) before and after the suspend/resume?

Also, if you connect a USB keyboard and/or mouse, does it still work after resume?

And, do I understand correctly that it worked with the older version, i.e. Leap 42.3?

Last but not least, does the problem persist with the recent upstream kernel, e.g. the kernel in OBS Kernel:stable repo?  You can install a newer kernel version on top of Leap 15.0 system (Nvidia binary driver might be a bit tricky, though).
Comment 2 Aman Vaishya 2018-11-06 12:53:51 UTC
(In reply to Aman Vaishya from comment #0)
> Sony Vaio SVF15218, Keyboard doesn't work after resume from sleep.
> The output of lspci is below.
> 
> 
> *00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM
> Controller (rev 09)
> 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor
> PCI Express Root Port (rev 09)
> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
> Graphics Controller (rev 09)
> 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
> Family USB xHCI Host Controller (rev 04)
> 00:16.0 Communication controller: Intel Corporation 7 Series/C216 Chipset
> Family MEI Controller #1 (rev 04)
> 00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB
> Enhanced Host Controller #2 (rev 04)
> 00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High
> Definition Audio Controller (rev 04)
> 00:1c.0 PCI bridge: Intel Corporation 7 Series/C216 Chipset Family PCI
> Express Root Port 1 (rev c4)
> 00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family
> PCI Express Root Port 2 (rev c4)
> 00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family
> PCI Express Root Port 3 (rev c4)
> 00:1d.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB
> Enhanced Host Controller #1 (rev 04)
> 00:1f.0 ISA bridge: Intel Corporation HM76 Express Chipset LPC Controller
> (rev 04)
> 00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port
> SATA Controller [AHCI mode] (rev 04)
> 00:1f.3 SMBus: Intel Corporation 7 Series/C216 Chipset Family SMBus
> Controller (rev 04)
> 01:00.0 3D controller: NVIDIA Corporation GK208M [GeForce GT 740M] (rev a1)
> 07:00.0 Network controller: Broadcom Limited BCM43142 802.11b/g/n (rev 01)
> 08:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5209 PCI
> Express Card Reader (rev 01)
> 0e:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)*
> 
> The kernel that I am using is *4.12.14-lp150.12.22-default*
> However the issue is there since I had upgraded to leap 15.0

(In reply to Takashi Iwai from comment #1)
> Could you give the output of hwinfo, and the kernel messages (dmesg output)
> before and after the suspend/resume?
> 
> Also, if you connect a USB keyboard and/or mouse, does it still work after
> resume?
> 
> And, do I understand correctly that it worked with the older version, i.e.
> Leap 42.3?
> 
> Last but not least, does the problem persist with the recent upstream
> kernel, e.g. the kernel in OBS Kernel:stable repo?  You can install a newer
> kernel version on top of Leap 15.0 system (Nvidia binary driver might be a
> bit tricky, though).
Comment 3 Aman Vaishya 2018-11-06 12:56:07 UTC
Created attachment 788618 [details]
Files, containing the output of the commands, as asked
Comment 4 Aman Vaishya 2018-11-06 12:56:52 UTC
(In reply to Aman Vaishya from comment #3)
> Created attachment 788618 [details]
> Files, containing the output of the commands, as asked

Hi Takashi,

I have attached the files, containing the output dmesg and hwinfo, the names would be self explanatory.

I tried with the USB keyboard and it was working totally fine after resume from suspend. The problem is only with my laptop keyboard.

I had faced this issue only with one kernel update in suse 42.3, the rest were working fine.

I did not try the OSD as I was facing issues while Bumblebee installation.
Comment 5 Takashi Iwai 2018-11-06 13:46:42 UTC
OK, then let's try some boot options.  Since it's a laptop keyboard, either i8042 or atkbd is releated.

First of all, try to pass i8042.reset=1
I guess this shouldn't bring any change on S2RAM, but let's be sure.

Then check i8042.noaux=1 option.  This will disable the touchpad or such, so test with USB mouse (or only with keyboard).

Also, atkbd.reset=1 might be interesting, too.

Another options would be i8042.dumbkbd=1 and i8042.direct=1
Comment 6 Takashi Iwai 2018-11-06 14:17:47 UTC
A likely relevant report in the upstream bugzilla:
   https://bugzilla.kernel.org/show_bug.cgi?id=195471
Comment 7 Aman Vaishya 2018-11-06 15:36:19 UTC
(In reply to Takashi Iwai from comment #6)
> A likely relevant report in the upstream bugzilla:
>    https://bugzilla.kernel.org/show_bug.cgi?id=195471

Out of all the options

i8042.noaux=1 is working fine but the touchpad isn't in this case and i8042.dumbkbd=1 is working but caps and num lock aren't turning off.
Comment 8 Takashi Iwai 2018-11-06 15:42:11 UTC
OK, then it's likely a relevant issue as the upstream bugzilla in comment 6.

The next thing to check: what happens if you boot with psmouse.synaptics_intertouch=1 boot option?  Does the touchpad still work?
If yes, please give the dmesg output.

If the touchpad works with that option, try to boot with both psmouse.synaptics_intertouch=1 and psmouse.noaux=1, and check the suspend/resume.
(Also it's interesting to test without psmouse.noaux=1 option.)
Comment 9 Aman Vaishya 2018-11-07 06:05:04 UTC
(In reply to Takashi Iwai from comment #8)
> OK, then it's likely a relevant issue as the upstream bugzilla in comment 6.
> 
> The next thing to check: what happens if you boot with
> psmouse.synaptics_intertouch=1 boot option?  Does the touchpad still work?
> If yes, please give the dmesg output.
> 
> If the touchpad works with that option, try to boot with both
> psmouse.synaptics_intertouch=1 and psmouse.noaux=1, and check the
> suspend/resume.
> (Also it's interesting to test without psmouse.noaux=1 option.)

With psmouse.synaptics_intertouch=1, the touchpad doesn't work, and also with both the arguments passed i.e. psmouse.synaptics_intertouch=1 and psmouse.noaux=1, it doesn't work either. However the keyboard is working after resume in both the cases.
Comment 10 Takashi Iwai 2018-11-10 08:38:17 UTC
OK, then there is no quick workaround, at least.

Could you try the kernel in OBS home:tiwai:bsc1114588 repo?
  https://download.opensuse.org/repositories/home:/tiwai:/bsc1114588/standard/

I'm not sure whether this would change anything useful, but let's try.
It contains a partial revert of the commit that was mentioned in the upstream bugzilla.
Comment 11 Aman Vaishya 2018-11-10 10:27:06 UTC
(In reply to Takashi Iwai from comment #10)
> OK, then there is no quick workaround, at least.
> 
> Could you try the kernel in OBS home:tiwai:bsc1114588 repo?
>  
> https://download.opensuse.org/repositories/home:/tiwai:/bsc1114588/standard/
> 
> I'm not sure whether this would change anything useful, but let's try.
> It contains a partial revert of the commit that was mentioned in the
> upstream bugzilla.

I downloaded the kernel kernel-default-4.12.14-lp150.1.1.g19df83d.x86_64.rpm and did an rpm install, and then updated the bootloader. While booting from this kernel I get an error message "You need to load the kernel first".
I am not sure how to move forward with this.
Comment 12 Takashi Iwai 2018-11-10 10:53:06 UTC
Weird, the kernel boots fine on my local machine.

Usually you don't have to touch bootloader things manually, just installing kernel-default should suffice.

Could you retry?  Uninstall the previous one, and just install the kernel-default.rpm either via rpm ("rpm -ivh --oldpackage kernel-default*.rpm") or zypper ("zypper in --oldpackage kernel-default*.rpm")
Comment 13 Aman Vaishya 2018-11-10 17:34:01 UTC
(In reply to Takashi Iwai from comment #12)
> Weird, the kernel boots fine on my local machine.
> 
> Usually you don't have to touch bootloader things manually, just installing
> kernel-default should suffice.
> 
> Could you retry?  Uninstall the previous one, and just install the
> kernel-default.rpm either via rpm ("rpm -ivh --oldpackage
> kernel-default*.rpm") or zypper ("zypper in --oldpackage
> kernel-default*.rpm")

My bad!
I had secure boot turned on. Btw this one is working fine after sleep.
Thanks.
Just for information, how long would it take for this bug to fixed and merged in the main releases?
Comment 14 Takashi Iwai 2018-11-11 08:10:11 UTC
That's interesting.  Honestly speaking, I didn't expect much that it really fixes.

As mentioned, it's a partial revert of the bisected commit (9d659ae14b) in the upstream bugzilla, and essentially a one-liner change as:

--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -59,7 +59,8 @@ 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 0x02
+#define MUTEX_FLAG_HANDOFF    0x00
 #define MUTEX_FLAG_PICKUP     0x04
 
 #define MUTEX_FLAGS           0x07

But this has basically nothing to do with the power management by itself.  What a surprise.

The fact that changing this fixes anything implies that the PM code in question is very messy, and the bug is likely in the code execution order.

So, at this point, I can't judge how long the fix would take.  We even don't know the real cause yet.  And the workaround above touches the very fundamental code, so we can't take it in our kernel, either.

Could you boot with i8042.debug=1 option on both the original and the patched (working) kernels, and attach the dmesg outputs after resume on both?
Comment 15 Aman Vaishya 2018-11-11 11:21:23 UTC
Created attachment 789306 [details]
attached file after passing i8042.debug=1

The zip file contains the dmesg output files of both the kernels after resume.
Comment 16 Takashi Iwai 2018-11-11 12:38:05 UTC
Unfortunately this flooded with typed or touchpad events.

Could you try to avoid using the build-in keyboard and touchpad, and instead use USB keyboard and mouse, then just test suspend/resume, and attach the dmesg outputs?  Thanks.
Comment 17 Aman Vaishya 2018-11-20 11:06:31 UTC
Created attachment 790265 [details]
Dmesg output after suspend with parameter i8042.debug=1

Attached the dmesg output after sleep.
Comment 18 Aman Vaishya 2018-12-29 04:28:08 UTC
Unfixed in the new kernel update 
4.12.14-lp150.12.28-default
Comment 19 Miroslav Beneš 2020-01-20 15:09:27 UTC
Just to note... still not fixed in upstream 5.3. No reports regarding 5.4 or 5.5 kernel.
Comment 20 Miroslav Beneš 2020-05-20 11:02:16 UTC
*** Bug 1134807 has been marked as a duplicate of this bug. ***
Comment 21 Miroslav Beneš 2020-09-10 10:35:31 UTC
Aman, the upstream bug report mentions that the issue may be gone with 5.7 kernel. Could you try the latest one from OBS Kernel:stable, please?
Comment 22 Aman Vaishya 2020-09-18 19:29:40 UTC
(In reply to Miroslav Beneš from comment #21)
> Aman, the upstream bug report mentions that the issue may be gone with 5.7
> kernel. Could you try the latest one from OBS Kernel:stable, please?

Hi Miroslav, Using kernel 5.8.0-1-default in tumbleweed, the issue seems to be fixed but partially. What I mean is :

Suspend -> wake-up -> the keyboard doesn't work.
Click on the list of users button -> select the user -> and the keyboard starts to work.

Also do let me know if the kernel version is fine or do I need to download a different OBS version.
Comment 23 Aman Vaishya 2020-09-19 08:07:54 UTC
(In reply to Aman Vaishya from comment #22)
> (In reply to Miroslav Beneš from comment #21)
> > Aman, the upstream bug report mentions that the issue may be gone with 5.7
> > kernel. Could you try the latest one from OBS Kernel:stable, please?
> 
> Hi Miroslav, Using kernel 5.8.0-1-default in tumbleweed, the issue seems to
> be fixed but partially. What I mean is :
> 
> Suspend -> wake-up -> the keyboard doesn't work.
> Click on the list of users button -> select the user -> and the keyboard
> starts to work.
> 
> Also do let me know if the kernel version is fine or do I need to download a
> different OBS version.

It's not working again, I don't think we have fix in this kernel version.
Comment 24 Miroslav Beneš 2020-09-21 07:44:30 UTC
Thanks for checking.

Could you try what Takashi proposed in comment 16? That is, external USB keyboard and mouse? If it makes any difference...
Comment 25 Miroslav Beneš 2021-12-31 14:43:16 UTC
No response, closing.