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