Bug 1436636

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 :(

The same thing happens with kernel 4.10.8-200.fc25.x86_64

 The same thing happens with kernel 4.10.10-200.fc25.x86_64

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>
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>
    Signed-off-by: Peter Zijlstra (Intel) <peterz>
    Reviewed-by: Waiman Long <Waiman.Long>
    Cc: Andrew Morton <akpm>
    Cc: Linus Torvalds <torvalds>
    Cc: Paul E. McKenney <paulmck.ibm.com>
    Cc: Peter Zijlstra <peterz>
    Cc: Thomas Gleixner <tglx>
    Cc: linux-kernel.org
    Signed-off-by: Ingo Molnar <mingo>

:040000 040000 4822b1795867b4e3f7d54dd35cdb8c883f4ca261 334ed2cd2f73eb3c670812500882eb956ae0ed46 M	kernel

4.8.6-300.fc25.x86_64 - this work correct

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

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

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?

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

$ dmesg | grep i8042
[    1.442049] i8042: PNP: No PS/2 controller found.

Same problem with kernel 4.10.15-200.fc25.x86_64

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.

This has been resolved for me since kernel-4.10.17-200.fc25.x86_64

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.

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>
Date:   Tue Aug 23 14:40:16 2016 +0200

    locking/mutex: Add lock handoff to avoid starvation

introduced this annoying problem

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.

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

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?

Yes, I reported it to upstream, see https://bugzilla.kernel.org/show_bug.cgi?id=195471

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

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.

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

?

I tried atkbd.reset=1 alone, but it is not working.

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.

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.

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?

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.

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.

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.

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

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.

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

Same issue here. But on Fedora 28, kernel 4.16.8-300.fc28.x86_64.

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

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

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

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

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

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 ~]$

This bug has been reported to LKML, see https://lkml.org/lkml/2018/8/31/707

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.

Kernel 4.18.11-200.fc28.x86_64 is *not* working.

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.

(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

connecting any kind of keyboard via USB fix this issue for me, i also resolved this issue on Fedora 27,28 by connecting Keyboard.

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

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

Kernel 4.20.13-200.fc29.x86_64 in NOT working

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.

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

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

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

Kernel 5.2.6-200.fc30.x86_64 still *NOT* working

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 ?

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

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

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.

Kernel 5.5.7-200.fc31.x86_64 on Fedora 31 is NOT working.

Kernel 5.6.12-300.fc32.x86_64 on Fedora 32 still NOT working.

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
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 '31'.

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

Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

This bug is still present in F33

I am running the latest Fedora 33 with kernel 5.9.14-200.fc33.x86_64 and this problem exists.  It doesn't happen every time I resume from suspend.  I'd say it happens once every 7-10 times.  This issue was present on F31 and F32 as well.

This problem still exists on F35

dmesg G i8042
[    0.444177] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    1.073111] i8042: Detected active multiplexing controller, rev 1.1
[    1.075798] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.076473] serio: i8042 AUX0 port at 0x60,0x64 irq 12
[    1.077751] serio: i8042 AUX1 port at 0x60,0x64 irq 12
[    1.078376] serio: i8042 AUX2 port at 0x60,0x64 irq 12
[    1.079026] serio: i8042 AUX3 port at 0x60,0x64 irq 12
[    1.085181] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
[    6.948218] input: PS/2 Synaptics TouchPad as /devices/platform/i8042/serio2/input/input10

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
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 '33'.

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

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
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 '33'.

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

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
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 '33'.

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

This bug is still present in F35 with kernel 5.15.12-200.fc35.x86_64

I might have a possible solution for some. I did not see it suggested here.

Try adding i8042.dritek=1.

Computer: HP Laptop 14-dq2040ca (Fedora recognizes it as 14-dq2xxx).
kernel: 5.16.8-200.fc35.x86_64

At boot sometimes the keyboard was non-responsive for up to 3 minutes. 
After waking from suspend the keyboard is non-responsive for up to 3 minutes. 

Oddly, the brightness controls always work (keys F2 and F3).
Trackpad always works. 

By adding i8042.dritek=1 

The keyboard works on boot and from suspend.

This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
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
'version' of '35'.

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

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 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 Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

This message is a reminder that Fedora Linux 37 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05.
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
'version' of '37'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 37 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 Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 37 entered end-of-life (EOL) status on None.

Fedora Linux 37 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

This bug is still present in f38 and maybe f39

This message is a reminder that Fedora Linux 38 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21.
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
'version' of '38'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 38 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 Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21.

Fedora Linux 38 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.