Bug 1436636 - Keyboard not working after resume with kernel 4.10.5-200.fc25.x86_64
Summary: Keyboard not working after resume with kernel 4.10.5-200.fc25.x86_64
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 31
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-28 11:06 UTC by Guido Aulisi
Modified: 2020-05-19 02:21 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-21 21:13:00 UTC
Type: Bug


Attachments (Terms of Use)
Patches the kernel to reset the keyboard after resuming from sleep (1.18 KB, patch)
2019-08-29 05:04 UTC, Stoica Tedy
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Linux Kernel 195471 None None None 2019-05-13 16:54:01 UTC

Description Guido Aulisi 2017-03-28 11:06:08 UTC
Description of problem:
After resuming the laptop, the keyboard is not working anymore with kernel 4.10.5-200.fc25.x86_64, but it worked with kernel 4.9.14-200.fc25.x86_64
I can resume with the keyboard, but after that I am stuck at the password prompt, which I can reach using the mouse or the trackball. The mouse and trackball are not affected. I can ssh into the laptop and reboot the machine.

Version-Release number of selected component (if applicable):
kernel 4.10.5-200.fc25.x86_64

How reproducible:
Always with my Sony Vaio VPCEH2H1E laptop

Steps to Reproduce:
1. Boot with kernel 4.10.5-200.fc25.x86_64
2. Put the laptop to sleep
3. Resume it (I can do this with the keyboard) 

Actual results:
The keyboard is not working, you can't type the password to unlock gnome

Expected results:
The keyboard works after resuming

Additional info:
Both mouse and trackball are working after resuming, the laptop seems working (but no keyboard), and I can ssh into it

Comment 1 Christopher Archer 2017-04-09 14:28:21 UTC
I have had a similar problem since updating the kernel to 4.10.5-200.fc25.x86_64 on my desktop.

If the screen is locked (manually or after display performs timed blank due to inactivity), attempting to unlock displays the login screen.

However, the mouse moves around but clicks don't register, and keyboard does not work at all - have to reset from computer itself.

Current "work around" is to not lock screen, which is far from ideal :(

Comment 2 Guido Aulisi 2017-04-11 09:06:42 UTC
The same thing happens with kernel 4.10.8-200.fc25.x86_64

Comment 3 Constantine 2017-04-20 11:54:09 UTC
 The same thing happens with kernel 4.10.10-200.fc25.x86_64

Comment 4 Guido Aulisi 2017-04-20 12:02:03 UTC
After a long bisection I got this commit, I will try to report this upstream too.

9d659ae14b545c4296e812c70493bfdc999b5c1c is the first bad commit
commit 9d659ae14b545c4296e812c70493bfdc999b5c1c
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Aug 23 14:40:16 2016 +0200

    locking/mutex: Add lock handoff to avoid starvation
    
    Implement lock handoff to avoid lock starvation.
    
    Lock starvation is possible because mutex_lock() allows lock stealing,
    where a running (or optimistic spinning) task beats the woken waiter
    to the acquire.
    
    Lock stealing is an important performance optimization because waiting
    for a waiter to wake up and get runtime can take a significant time,
    during which everyboy would stall on the lock.
    
    The down-side is of course that it allows for starvation.
    
    This patch has the waiter requesting a handoff if it fails to acquire
    the lock upon waking. This re-introduces some of the wait time,
    because once we do a handoff we have to wait for the waiter to wake up
    again.
    
    A future patch will add a round of optimistic spinning to attempt to
    alleviate this penalty, but if that turns out to not be enough, we can
    add a counter and only request handoff after multiple failed wakeups.
    
    There are a few tricky implementation details:
    
     - accepting a handoff must only be done in the wait-loop. Since the
       handoff condition is owner == current, it can easily cause
       recursive locking trouble.
    
     - accepting the handoff must be careful to provide the ACQUIRE
       semantics.
    
     - having the HANDOFF bit set on unlock requires care, we must not
       clear the owner.
    
     - we must be careful to not leave HANDOFF set after we've acquired
       the lock. The tricky scenario is setting the HANDOFF bit on an
       unlocked mutex.
    
    Tested-by: Jason Low <jason.low2@hpe.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Waiman Long <Waiman.Long@hpe.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

:040000 040000 4822b1795867b4e3f7d54dd35cdb8c883f4ca261 334ed2cd2f73eb3c670812500882eb956ae0ed46 M	kernel

Comment 5 Constantine 2017-04-20 12:07:57 UTC
4.8.6-300.fc25.x86_64 - this work correct

Comment 6 Guido Aulisi 2017-04-20 12:21:29 UTC
Yes because the above commit is only present in kernels 4.10.y and maybe 4.11.

So I think 4.9.y should work too, 4.9.14-200.fc25.x86_64 was the latest working Fedora kernel IMHO

Comment 7 Guido Aulisi 2017-04-23 10:20:03 UTC
This is some of dimes output after resuming.
IMHO this line is important:
[ 1095.609531] i8042: Can't reactivate AUX port

[ 1084.608121] wlp7s0: deauthenticating from 00:25:9c:28:07:6a by local choice (Reason: 3=DEAUTH_LEAVING)
[ 1084.649203] IPv6: ADDRCONF(NETDEV_UP): wlp7s0: link is not ready
[ 1089.708770] PM: Syncing filesystems ... done.
[ 1091.271499] PM: Preparing system for sleep (mem)
[ 1091.271662] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 1091.273516] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 1091.274777] PM: Suspending system (mem)
[ 1091.274846] Suspending console(s) (use no_console_suspend to debug)
[ 1091.275183] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 1091.288328] ACPI : EC: event blocked
[ 1091.318825] sd 0:0:0:0: [sda] Stopping disk
[ 1091.707368] PM: suspend of devices complete after 432.440 msecs
[ 1091.707373] PM: suspend devices took 0.433 seconds
[ 1091.720049] PM: late suspend of devices complete after 12.670 msecs
[ 1091.721015] ACPI : EC: interrupt blocked
[ 1091.721563] r8169 0000:13:00.0: System wakeup enabled by ACPI
[ 1091.721869] ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI
[ 1091.722134] ehci-pci 0000:00:1a.0: System wakeup enabled by ACPI
[ 1091.733947] PM: noirq suspend of devices complete after 13.892 msecs
[ 1091.734608] ACPI: Preparing to enter system sleep state S3
[ 1091.735642] ACPI : EC: EC stopped
[ 1091.735643] PM: Saving platform NVS memory
[ 1091.737055] Disabling non-boot CPUs ...
[ 1091.739457] smpboot: CPU 1 is now offline
[ 1091.742159] smpboot: CPU 2 is now offline
[ 1091.744961] smpboot: CPU 3 is now offline
[ 1091.746798] ACPI: Low-level resume complete
[ 1091.746857] ACPI : EC: EC started
[ 1091.746857] PM: Restoring platform NVS memory
[ 1091.747326] Suspended for 3215.477 seconds
[ 1091.748054] Enabling non-boot CPUs ...
[ 1091.748093] x86: Booting SMP configuration:
[ 1091.748094] smpboot: Booting Node 0 Processor 1 APIC 0x1
[ 1091.750898]  cache: parent cpu1 should not be sleeping
[ 1091.751246] CPU1 is up
[ 1091.751313] smpboot: Booting Node 0 Processor 2 APIC 0x2
[ 1091.754483]  cache: parent cpu2 should not be sleeping
[ 1091.754620] microcode: sig=0x206a7, pf=0x10, revision=0x14
[ 1091.755609] microcode: updated to revision 0x29, date = 2013-06-12
[ 1091.755962] CPU2 is up
[ 1091.756023] smpboot: Booting Node 0 Processor 3 APIC 0x3
[ 1091.759136]  cache: parent cpu3 should not be sleeping
[ 1091.759297] microcode: sig=0x206a7, pf=0x10, revision=0x29
[ 1091.759599] CPU3 is up
[ 1091.767761] ACPI: Waking up from system sleep state S3
[ 1091.769175] ACPI : EC: interrupt unblocked
[ 1091.781728] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI
[ 1091.782115] ehci-pci 0000:00:1a.0: System wakeup disabled by ACPI
[ 1091.782198] PM: noirq resume of devices complete after 13.158 msecs
[ 1091.782667] PM: early resume of devices complete after 0.362 msecs
[ 1091.782793] ACPI : EC: event unblocked
[ 1091.783062] r8169 0000:13:00.0: System wakeup disabled by ACPI
[ 1091.784022] ath: phy0: ASPM enabled: 0x43
[ 1091.788624] sd 0:0:0:0: [sda] Starting disk
[ 1091.914334] r8169 0000:13:00.0 enp19s0: link down
[ 1092.001833] usb 1-1.5: reset full-speed USB device number 5 using ehci-pci
[ 1092.044070] rtc_cmos 00:01: System wakeup disabled by ACPI
[ 1092.079997] usb 1-1.5: device firmware changed
[ 1092.080285] PM: resume of devices complete after 297.637 msecs
[ 1092.080623] PM: resume devices took 0.298 seconds
[ 1092.080659] PM: Finishing wakeup.
[ 1092.080661] Restarting tasks ... 
[ 1092.080990] usb 1-1.5: USB disconnect, device number 5
[ 1092.083015] done.
[ 1092.095811] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1092.114760] ata4.00: configured for UDMA/66
[ 1092.159825] usb 1-1.5: new full-speed USB device number 6 using ehci-pci
[ 1092.239153] usb 1-1.5: New USB device found, idVendor=0489, idProduct=e027
[ 1092.239159] usb 1-1.5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1092.552681] usb 1-1.5: USB disconnect, device number 6
[ 1093.236705] usb 1-1.5: new full-speed USB device number 7 using ehci-pci
[ 1093.293852] video LNXVIDEO:01: Restoring backlight state
[ 1093.315596] usb 1-1.5: New USB device found, idVendor=0cf3, idProduct=3005
[ 1093.315600] usb 1-1.5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1093.338288] IPv6: ADDRCONF(NETDEV_UP): enp19s0: link is not ready
[ 1093.480732] r8169 0000:13:00.0 enp19s0: link down
[ 1093.480807] IPv6: ADDRCONF(NETDEV_UP): enp19s0: link is not ready
[ 1093.481989] IPv6: ADDRCONF(NETDEV_UP): wlp7s0: link is not ready
[ 1093.501901] IPv6: ADDRCONF(NETDEV_UP): wlp7s0: link is not ready
[ 1093.528571] IPv6: ADDRCONF(NETDEV_UP): wlp7s0: link is not ready
[ 1094.749460] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1094.761062] ata1.00: configured for UDMA/133
[ 1095.087438] i8042: Can't write CTR while closing AUX port
[ 1095.609531] i8042: Can't reactivate AUX port
[ 1095.634863] IPv6: ADDRCONF(NETDEV_UP): wlp7s0: link is not ready
[ 1096.606045] IPv6: ADDRCONF(NETDEV_UP): wlp7s0: link is not ready
[ 1097.088351] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input14
[ 1097.593055] wlp7s0: authenticate with 00:25:9c:28:07:6a
[ 1097.609767] wlp7s0: send auth to 00:25:9c:28:07:6a (try 1/3)
[ 1097.616308] wlp7s0: authenticated
[ 1097.616506] ath9k 0000:07:00.0 wlp7s0: disabling HT as WMM/QoS is not supported by the AP
[ 1097.616509] ath9k 0000:07:00.0 wlp7s0: disabling VHT as WMM/QoS is not supported by the AP
[ 1097.617177] wlp7s0: associate with 00:25:9c:28:07:6a (try 1/3)
[ 1097.622692] wlp7s0: RX AssocResp from 00:25:9c:28:07:6a (capab=0x431 status=0 aid=6)
[ 1097.622906] wlp7s0: associated
[ 1097.622960] IPv6: ADDRCONF(NETDEV_CHANGE): wlp7s0: link becomes ready
[ 1098.769224] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input16

Comment 8 Christopher Archer 2017-04-23 17:10:49 UTC
Don't know if this will help, but I'm currently running 

Linux hostname 4.10.10-200.fc25.x86_64 #1 SMP Thu Apr 13 01:11:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Using NVIDIA's drivers as per
https://www.if-not-true-then-false.com/2015/fedora-nvidia-guide/

and everything works fine.

Again, not a solution but hopefully will provide some insight on solving the problem and/or an alternative for now until a "proper" solution is found.

Are there any files I can provide that would assist investigation?

Comment 9 Guido Aulisi 2017-04-24 13:57:00 UTC
This problem seems related to the i8042 keyboard and mouse controller driver and mutex locking to me.

Could you run "dmesg | grep i8042" to see if you have an AT keyboard, you should get something like this:

[    0.815056] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    0.827968] serio: i8042 KBD port at 0x60,0x64 irq 1
[    0.827974] serio: i8042 AUX port at 0x60,0x64 irq 12
[    0.868779] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
[    2.177096] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input5

If you don't get a line for the AT keyboard, then you are not using this type of keyboard and you shouldn't have this problem (IMHO, I'm not a keyboard driver expert).

Comment 10 Christopher Archer 2017-04-25 14:13:35 UTC
$ dmesg | grep i8042
[    1.442049] i8042: PNP: No PS/2 controller found.

Comment 11 Guido Aulisi 2017-05-16 17:22:42 UTC
Same problem with kernel 4.10.15-200.fc25.x86_64

Comment 12 Guido Aulisi 2017-06-14 14:56:27 UTC
Same problem with kernel 4.11.3-202.fc25.x86_64

I noticed that when resuming the touchpad is detected twice and the keyboard is never detected, the important dmesg lines are:

[ 1095.087438] i8042: Can't write CTR while closing AUX port
[ 1095.609531] i8042: Can't reactivate AUX port
[ 1097.088351] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input14
[ 1098.769224] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input16

I will try a working kernel ASAP to see if it reports the same messages or not.

Comment 13 Christopher Archer 2017-06-14 16:39:35 UTC
This has been resolved for me since kernel-4.10.17-200.fc25.x86_64

Comment 14 Guido Aulisi 2017-06-14 22:43:33 UTC
I think your issue was different, my problem is in the PS2 keyboard (i8042 driver) and you don't have a PS2 keyboard and mouse.

Comment 15 Guido Aulisi 2017-06-15 20:42:39 UTC
I tried an old working kernel and I found that the logs are the same as the not working one:

i8042: Can't write CTR while closing AUX port
i8042: Can't reactivate AUX port
input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input14
input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input16

Also I had an external usb mouse attached, could this explain the double line?

The message "Can't reactivate AUX port" is present in the working kernel too, so this should not be the problem.

So I'm a little bit confused about this problem, but I'm quite sure the bisection was correct, the

commit 9d659ae14b545c4296e812c70493bfdc999b5c1c
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Aug 23 14:40:16 2016 +0200

    locking/mutex: Add lock handoff to avoid starvation

introduced this annoying problem

Comment 16 Christopher Archer 2017-06-16 01:10:19 UTC
Good point. Just realized I also still have the NVidia driver installed (as mentioned in comment #8) which might be why I'm not affected.

Comment 17 Pablo Zanitti 2017-09-08 14:41:09 UTC
Any updates? Mine is a Vaio SVE141D11L. It's been broken for months but I don't recall since which version. Kernel is currently 4.12.9-300.fc26.x86_64.

No Nvidia driver since VGA is Intel.

PS/2 keyboard and mouse, apparently.

$ dmesg | grep i8042
[    2.214810] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    2.219179] serio: i8042 KBD port at 0x60,0x64 irq 1
[    2.219183] serio: i8042 AUX port at 0x60,0x64 irq 12
[    2.242115] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
[    3.051246] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input5

Comment 18 diego.amores 2017-09-08 15:45:50 UTC
I can confirm that keyboard is not working after resume from suspend on a Sony Vaio SVF15A1B4E. A git bisect on the linux-stable master branch gave me the same results as stated in comments #4 and #15 (first bad commit is 9d659ae).

Was this bug ever reported to upstream?

Comment 19 Guido Aulisi 2017-09-09 14:44:02 UTC
Yes, I reported it to upstream, see https://bugzilla.kernel.org/show_bug.cgi?id=195471

Comment 20 Guido Aulisi 2017-09-22 08:10:14 UTC
Some tests, reported upstream:

i8042.debug=1 i8042.reset=1	NOT WORKING
i8042.debug=1 i8042.kbdreset=1	NOT WORKING
i8042.debug=1 i8042.nomux=1	NOT WORKING
i8042.debug=1 i8042.noaux=1	KEYBOARD WORKING, BUT TRACKPAD NOT WORKING (obviously)

I think that the driver can wake only one device, when I used i8042.noaux=1 it was able to resume the keyboard, but the trackball doesn't work from cold boot of course (I used an USB mouse).

I'm still confident that the commit

commit 9d659ae14b545c4296e812c70493bfdc999b5c1c
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Aug 23 14:40:16 2016 +0200

introduced this problem, but I've not been able to revert it to test if current kernels work.
If possible we should try to disable lock handoff and see if it works again.

Comment 21 Fedora End Of Life 2017-11-16 19:30:53 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 22 Marcos Paulo 2017-11-22 00:37:40 UTC
(In reply to Guido Aulisi from comment #20)
> Some tests, reported upstream:
> 
> i8042.debug=1 i8042.reset=1	NOT WORKING
> i8042.debug=1 i8042.kbdreset=1	NOT WORKING
> i8042.debug=1 i8042.nomux=1	NOT WORKING
> i8042.debug=1 i8042.noaux=1	KEYBOARD WORKING, BUT TRACKPAD NOT WORKING
> (obviously)
> 
> I think that the driver can wake only one device, when I used i8042.noaux=1
> it was able to resume the keyboard, but the trackball doesn't work from cold
> boot of course (I used an USB mouse).
> 
> I'm still confident that the commit
> 
> commit 9d659ae14b545c4296e812c70493bfdc999b5c1c
> Author: Peter Zijlstra <peterz@infradead.org>
> Date:   Tue Aug 23 14:40:16 2016 +0200
> 
> introduced this problem, but I've not been able to revert it to test if
> current kernels work.
> If possible we should try to disable lock handoff and see if it works again.

can you please also try to add the following option?

atkbd.reset=1

?

Comment 23 Guido Aulisi 2017-11-27 23:28:18 UTC
I tried atkbd.reset=1 alone, but it is not working.

Comment 24 aaronsloman 2018-01-24 09:52:26 UTC
I had this problem on a Stonebook Mini laptop (re-badged Clevo w515lu), with the latest available kernel: 4.13.16-100.fc25.x86_64 dual-booting with Windows 10.

After a boot, and sometimes after hibernate/resume fedora ignored keypresses. However, it worked with an external usb keyboard. Windows had no problem.

For a while I used a procedure discovered by accident: if I shut the lid, causing suspend, then a short time later after resume from suspend the keyboard worked. I could not recognize any evidence in /var/log/messages or in dmesg output indicating that anything was wrong or what had been changed by suspend+resume.

Anyhow, since I happened to have the files for the previous kernel in /boot, namely 4.8.6-300.fc25.x86_64, I edited grub.cfg to use that as the default and now the laptop boots perfectly. I have not used it long enough since then to detect any old bugs re-introduced by that kernel.

I am too busy to upgrade now, but when I get time I'll upgrade to f27, hoping that does not have the problem.

Comment 25 aaronsloman 2018-01-24 10:08:25 UTC
In my previous comment I forgot to mention that I normally boot to level 3 in case any maintenance work is required, and then run startx (+ ~/.xinitrc) and use the recently revived ctwm window manager, and thereafter simply use hibernate/resume until some maintenance problem or a kernel update requires a reboot.

After resume from hibernate I had the same problem as after rebooting: I had to use suspend+resume to get the keyboard working.

In view of comment #8 I tried using dnf to install 
4.10.10-200.fc25.x86_64 but got:

No package kernel-4.10.10-200.fc25.x86_64 available.
Error: Unable to find a match.

Comment 26 aaronsloman 2018-01-24 23:31:32 UTC
In my previous comment I referred to kernel 4.10.10-200.fc25.x86_64 in comment #8. I now realise I should have referred to comment #6 which states:

> 4.9.14-200.fc25.x86_64 was the latest working Fedora kernel IMHO

However, I have not been able find that online either.

I now wonder whether I would regret upgrading from f25 to Fedora 27, if the problem has not been fixed there.

Or has it been?

Comment 27 Guido Aulisi 2018-01-25 07:55:43 UTC
FWIK it has not been resolved.

Fedora doesn't keep all the packages, they are deleted as soon as an updated package is published, so you can't find 4.9.14-200.fc25.x86_64 any more.

Fedora 25 is now at end of life, so no new updates are released for it.

You can build it on your own, it's not so difficult, but I think it's not worth it, because that is an old kernel, which may contain bugs and security issues.

What we can try to do as a community, is to help solve this bug, with new reports or feedback, or try to solve it by ourselves. I tried some patching of the code some time ago, but I had no luck.

Comment 28 aaronsloman 2018-01-25 10:26:56 UTC
Thanks for the comments
(In reply to Guido Aulisi from comment #27)
> FWIK it has not been resolved.
> 
> You can build it on your own, it's not so difficult, but I think it's not
> worth it, because that is an old kernel, which may contain bugs and security
> issues.

I lack the expertise to do that, though if anyone wishes to give me detailed instructions I am willing to help with debugging, after I return from my travels in about a week from now. Normally the laptop is not my main machine, so I can experiment on it.

I now realise that when I thought my attempt a week ago to install F27 (+XFCE) from a 'live' usb stick had failed, because the keyboard would not respond after rebooting, it must have been this bug. I assumed the installation was broken and deleted it, returning to F25.

If I had realised then that suspend by shutting the lid then resume by opening it could restore keyboard functionality, I might have persisted, but instead I removed the installation and returned to F25 as I needed to prepare for conference travel next week.

I have helped an expert a few years ago, when hibernate/resume was unreliable and he eventually got it working perfectly partly on the basis of my feedback. I can do similar testing and reporting in this case if it would help, e.g. if I am given a link to an experimental package to try.

Perhaps it would be better if I reinstalled the buggy F27 next week in a separate partition, and experimented from there. I can keep F25 going in parallel for a while, by editing grub.cfg. But I would need someone to tell me exactly how to fetch and install test kernel code -- perhaps "instrumented" code. I can then report contents of log files. But I can't do anything till 1st or 2nd February.

Thanks.

Comment 29 Guido Aulisi 2018-01-25 11:22:18 UTC
This bug is triggered by suspend (to ram) and resume. Not rebooting. When you reboot the keyboard is ok. Maybe you are hitting some other bug.
And as far as I can understand only some Sony laptops are affected.

You should try the latest kernel and see if your problem is still present, then file another bug if it is.

Comment 30 aaronsloman 2018-01-25 14:11:04 UTC
(In reply to Guido Aulisi from comment #29)
> This bug is triggered by suspend (to ram) and resume. Not rebooting.

My apologies: when I read

> Put the laptop to sleep

and what looked like a description of my symptoms, I assumed it was the same problem. (Hibernation can also be thought of as putting to sleep.)

It seems that various people are experiencing loss of keyboard input after suspend/resume, hibernate/resume, reboot, and in some cases (e.g. my laptop), after hibernate/resume loses keyboard access, suspend/resume restores its functionality.

(I have found several partly different partly similar reports, on this forum and on others.)

This makes me wonder whether there's something unclean about the design of the linux keyboard (and mouse) interfaces. But I am out of my depth.

> And as far as I can understand only some Sony laptops are affected.

I've seen several others referred to in the reports. Mine is a 'Stonebook mini', which is a re-badged Clevo-W515LU.

> You should try the latest kernel and see if your problem is still present,
> then file another bug if it is.

I'll try again with F27 later.

Thanks for pointing out my mistake.

Comment 31 aaronsloman 2018-02-10 19:16:52 UTC
This a followup to "I'll try again with F27 later" in the previous comment. I am now running F27 
4.14.16-300.fc27.x86_64 #1 SMP Wed Jan 31 19:24:27 UTC 2018
on my Stonebook mini laptop, which is a re-badged Clevo W515LU, with some odd results, that may or may not be related to this bug. I mention them here in case it sheds any light on this bug.

I now don't seem to have problems with resume from either suspend or hibernate: in both cases the laptop keyboard works. However if I boot the machine while running kernel 4.14.16 I cannot get the keyboard to work, though it allows one or two characters to be typed -- not enough to login. This is true both if I boot in text mode (3) or graphical mode (5). The laptop's touchpad seems to be ignored also.

However, if I plug in a USB keyboard it works perfectly, and likewise a useb mouse. (Fortunately, this mini laptop has three USB sockets).

However, in both cases, if I shut the lid long enough to suspend then after it resumes from suspend (i.e. a few seconds after opening the lid) all keyboard and mouse input is normal. I can then login (whether in mode 3 or mode 5) and everything works as normal.

That was also true previously when running 4.13.16-100.fc25.x86_64, but in that case the keyboard and touchpad did not work after hibernate until "fixed" by suspend+resume (using laptop lid).

In contrast, running  4.14.16-300.fc27 once I have logged in, the keyboard and touchpad are available after hibernate and resume, as well as after suspend+resume.

There seems to be a timeout mechanism running in F27 that puts the machine into some kind of inactive state if not used for a while. In that case the keyboard and mouse can't be used to wake it up, but shutting and opening the lid (suspend/resume) works. But in that state (keyboard and mouse not working) the laptop is not in suspend mode because I can log in from my desktop! The loss of keyboard mouse access can happen even while I am working on the machine via the PC (running F24!) because it has a big screen and full keyboard.

I have not found a remote command that has the same effect as suspend/resume in reviving the keyboard and touchpad.

I am completely mystified.
(Incidentally the screen handling is much improved in F26 --  no more tearing and font-mangling).

I hope this information gives somebody some ideas.

Comment 32 Guido Aulisi 2018-04-06 19:22:17 UTC
Kernel 4.15.14-300.fc27.x86_64 still not working.
Using atkbd.reset=1 I get these messages:

kernel: i8042: Can't write CTR while closing AUX port
kernel: i8042: Can't reactivate AUX port
kernel: atkbd serio1: keyboard reset failed on isa0060/serio1

Comment 33 Vinicius Reis 2018-05-20 03:19:21 UTC
Same issue here. But on Fedora 28, kernel 4.16.8-300.fc28.x86_64.

Comment 34 Vinicius Reis 2018-05-22 02:28:28 UTC
Just forgot to post it before, my computer has the i8042 controller.

$ dmesg | grep i8042
[    0.712304] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    0.716422] serio: i8042 KBD port at 0x60,0x64 irq 1
[    0.716426] serio: i8042 AUX port at 0x60,0x64 irq 12
[    0.737824] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
[    2.721637] input: PS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input6

Comment 35 Justin M. Forbes 2018-07-23 15:12:22 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.

Fedora 27 has now been rebased to 4.17.7-100.fc27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28.

If you experience different issues, please open a new bug report for those.

Comment 36 alpenrise 2018-08-23 12:55:35 UTC
Did have the same problem after fresh install of Fedora 28,then I installed Fedora 27, no problems worked fine untill updating 90 or so MBs, then no more keyboard! found an advice to downgrade a few things: sudo dnf downgrade libebitdo libdfu fwupd storaged libstoraged libinput

and miracle it works, so I carefully did new updates with out including those files, and it works, but today, I thought to test it, and updated those files one by one, and it is in updating the: libinput, that my keyboard stoped fonctioning again, and worked again after doing a: sudo dnf downgrade libinput

Many thanks to every one for all the work you are putting out for that grate op.system that is Fedora! I may now pass to Fedora 28, but with out the :libinput part of it!
Regards,

alpenrise

Comment 37 alpenrise 2018-08-29 05:47:37 UTC
fergot to add: did a log-out log-in, or reboot after downgrading libinput for changes to take place, and my system is single-booted on an Asus vivobook flip TP412UA manufacturd July 2018 running Fedora 27  kernel: 4.17.17-100.fc27.x86_64   Intel© Core™ i3-8130U CPU 

Best regards,  alpenrise

Comment 38 Guido Aulisi 2018-08-29 06:11:30 UTC
I think you are hitting some other bug. This bug is triggered by suspend to ram and resume and it's related to the i8042 keyboard and mouse controller driver.

You can run "dmesg | grep i8042" to see if you have an AT keyboard, see https://bugzilla.redhat.com/show_bug.cgi?id=1436636#c9

Comment 39 alpenrise 2018-08-29 06:58:54 UTC
This is result of dmesg.....:


[sunrise@localhost ~]$ dmesg | grep i8042
[    0.975166] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[    0.975166] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
[    0.978389] serio: i8042 KBD port at 0x60,0x64 irq 1
[    0.986062] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
[sunrise@localhost ~]$

Comment 40 Guido Aulisi 2018-09-02 10:45:01 UTC
This bug has been reported to LKML, see https://lkml.org/lkml/2018/8/31/707

Comment 41 Laura Abbott 2018-10-01 21:21:40 UTC
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs.
 
Fedora 28 has now been rebased to 4.18.10-300.fc28.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29.
 
If you experience different issues, please open a new bug report for those.

Comment 42 Guido Aulisi 2018-10-07 15:12:09 UTC
Kernel 4.18.11-200.fc28.x86_64 is *not* working.

Comment 43 Erfan Bonyadi 2018-12-12 07:40:06 UTC
Kernel: 4.19.4-300.fc29.x86_64

dmesg output:

dmesg |grep i8042
[    1.211823] i8042: PNP: PS/2 Controller [PNP030b:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    1.215371] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.215377] serio: i8042 AUX port at 0x60,0x64 irq 12
[    1.240001] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
[    1.774716] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input5

Laptop Vaio SVF152C23W/SVF1521BYG, i had this issue from Fedora 27.

Comment 44 Guido Aulisi 2018-12-12 10:01:11 UTC
(In reply to Erfan Bonyadi from comment #43)
> Kernel: 4.19.4-300.fc29.x86_64
> 

Please report your problem upstream too:

https://bugzilla.kernel.org/show_bug.cgi?id=195471

Comment 45 Erfan Bonyadi 2018-12-16 09:45:01 UTC
connecting any kind of keyboard via USB fix this issue for me, i also resolved this issue on Fedora 27,28 by connecting Keyboard.

Comment 46 Justin M. Forbes 2019-01-29 16:25:06 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs.

Fedora 28 has now been rebased to 4.20.5-100.fc28.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29.

If you experience different issues, please open a new bug report for those.

Comment 47 Justin M. Forbes 2019-02-21 21:13:00 UTC
*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.

Comment 48 Guido Aulisi 2019-03-10 18:29:34 UTC
Kernel 4.20.13-200.fc29.x86_64 in NOT working

Comment 49 eisenhowerj 2019-07-31 00:15:17 UTC
I've been dealing with this bug since for two years now and was really hoping a fresh install of fc30 would fix the problem.  Much to my dismay it just happened again.  For fc29 and fc28 I had a simple shell script that would reset the mouse 95% of the time:

echo -n "none" > /sys/devices/platform/i8042/serio1/drvctl

I'm curious if the problem actually exists in Gnome/X/Wayland. I can move the mouse but cannot click. Maybe I'll install a different window manager and see if that helps.

Comment 50 Erfan Bonyadi 2019-08-03 05:54:20 UTC
I'm Still have issue with this bug in Fedora 30 Mate Desktop with following kernel:
5.1.20-300.fc30.x86_64 #1 SMP Fri Jul 26 15:03:11 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

what exactly should i attach or post as a relevant data?

thanks

Comment 51 Erfan Bonyadi 2019-08-03 06:00:08 UTC
actually now that i'm checking it's fixed! last night i had issue but now it's fixed!! 
5.1.20-300.fc30.x86_64 #1 SMP Fri Jul 26 15:03:11 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux issue solved suddenly!!

Comment 52 Erfan Bonyadi 2019-08-03 17:50:42 UTC
Edit:
As i restart system and checked again, this issue still existed and I think in previous post i had a physical keyboard attached to my system, sry for wrong information before, so what should i share as relevant information ??

Comment 53 Guido Aulisi 2019-08-14 13:58:04 UTC
Kernel 5.2.6-200.fc30.x86_64 still *NOT* working

Comment 54 Stoica Tedy 2019-08-29 05:04:54 UTC
Created attachment 1609202 [details]
Patches the kernel to reset the keyboard after resuming from sleep

Can somebody test this patch on v5.3-rc6 kernel and see if this fixes the issue for them? 
This patch needs `i8042.kbdreset` as a kernel argument to force the kernel to reset the keyboard. 
If it does not still work, can somebody test if pressing CAPS repeatedly at startup until the caps lock lights start is making the keyboard work ?

Comment 55 Sebastian Dato 2019-09-29 15:43:22 UTC
I am running fedora 30 with kernel 5.3.0-1.fc31.x86_64, I added i8042.kbdreset to the boot parameters and still having the same problem. The options that seems to work for me are "i8042.direct i8042.dumbkbd" with the problem that the keyboard indicator lights does not work after adding those lines.

I have a Sony VAIO SVF14A15CXB and this is the hardware:

[    1.592205] i8042: PNP: PS/2 Controller [PNP030b:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    1.596851] i8042: Attempting to reset device connected to KBD port
[    1.597176] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.597182] serio: i8042 AUX port at 0x60,0x64 irq 12
[    1.618472] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
[    2.101982] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input5

Comment 56 Justin M. Forbes 2020-03-03 16:29:54 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs.

Fedora 30 has now been rebased to 5.5.7-100.fc30.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31.

If you experience different issues, please open a new bug report for those.

Comment 57 Erfan Bonyadi 2020-03-05 18:34:04 UTC
Hello,

I'm @ Fedora 31 with following Kernel: 5.4.17-200.fc31.x86_64 #1 SMP Sat Feb 1 19:00:13 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

I'm Still have This issue, and the only way to recover is to attach a USB KEYBOARD which fix this issue for me.

B.R.

Comment 58 Guido Aulisi 2020-03-08 18:40:54 UTC
Kernel 5.5.7-200.fc31.x86_64 on Fedora 31 is NOT working.

Comment 59 Vinicius Reis 2020-05-19 02:21:13 UTC
Kernel 5.6.12-300.fc32.x86_64 on Fedora 32 still NOT working.


Note You need to log in before you can comment on or make changes to this bug.