+++ This bug was initially created as a clone of Bug #813587 +++ Created attachment 578198 [details] Output of "lsusb -vvv" (with the trackpad information) Description of problem: When I'm back from suspend, the keyboard don't respond to some random keys. With a "dmesg" command, I can see some errors. This is part of the /var/log/messages file: Apr 17 21:10:45 prometheus kernel: [ 8203.078028] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 17 21:10:45 prometheus kernel: [ 8203.080089] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 17 21:10:45 prometheus kernel: [ 8203.598990] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 17 21:10:45 prometheus kernel: [ 8203.600795] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 17 21:10:46 prometheus kernel: [ 8204.113724] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 17 21:10:46 prometheus kernel: [ 8204.113732] psmouse.c: issuing reconnect request Apr 17 21:10:47 prometheus kernel: [ 8205.340666] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 17 21:10:47 prometheus kernel: [ 8205.342540] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 17 21:10:47 prometheus kernel: [ 8205.855431] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 17 21:10:47 prometheus kernel: [ 8205.857342] psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Apr 17 21:10:55 prometheus kernel: [ 8212.877752] psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched. Version-Release number of selected component (if applicable): xorg-x11-drv-mouse-1.7.1-2.fc16.x86_64 kernel-3.1.2-1.fc16.x86_64 How reproducible: Just suspend and back. The problem don't happen when back from hibernate or cold turn on. This stopped when I de-activate the trackpad and activate it again. My hardware is a Dell Vostro V13. --- Additional comment from Josh Boyer on 2012-04-18 08:46:13 EDT --- 3.1.2-1 is relatively old at this point. Could you please try the latest 3.3.1-5 in F16 updates, or even 3.3.2-1.fc16 and let us know if the problem persists? --- Additional comment from Jonathan Dieter on 2012-04-24 10:31:28 EDT --- I'm seeing this on my HP dv6t on both up-to-date Fedora 16 and Fedora 17 with updates-testing enabled. Using i8042.dumbkbd and i8042.reset (which was suggested by Google) on the kernel boot line doesn't have any effect. I only started hitting this sometime over the last month, but I'm not sure what changed. --- Additional comment from Jonathan Dieter on 2012-04-25 14:43:36 EDT --- FWIW, typing "echo -n rescan > /sys/devices/platform/i8042/serio1/drvctl" fixes the problem for me (though it reappears when after another suspend/resume cycle). --- Additional comment from Jonathan Dieter on 2012-04-25 14:44:28 EDT --- In the previous comment, s/when after/after/ --- Additional comment from Dave Jones on 2012-10-23 11:37:12 EDT --- # Mass update to all open bugs. Kernel 3.6.2-1.fc16 has just been pushed to updates. This update is a significant rebase from the previous version. Please retest with this kernel, and let us know if your problem has been fixed. In the event that you have upgraded to a newer release and the bug you reported is still present, please change the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. If you are not the original bug reporter and you still experience this bug, please file a new report, as it is possible that you may be seeing a different problem. (Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient). --- Additional comment from Dennis Burdick on 2012-10-26 19:56:11 EDT --- It's still the same. Works great after fresh boot, but after waking from sleep the keyboard not very responsive. It frequently pauses for a second or so, and ignores any keystrokes made during that time. As reported /var/messages shows what is listed below during that time period... Oct 26 17:45:03 donna kernel: [ 90.920141] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4 Oct 26 17:45:03 donna kernel: [ 90.921335] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Oct 26 17:45:03 donna kernel: [ 90.922971] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Oct 26 17:45:03 donna kernel: [ 90.924531] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Oct 26 17:45:03 donna kernel: [ 90.925755] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 Oct 26 17:45:03 donna kernel: [ 90.925763] psmouse serio1: issuing reconnect request Reference: Fedora release 17 (Beefy Miracle) Linux donna 3.6.2-4.fc17.x86_64 #1 SMP Wed Oct 17 02:43:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux --- Additional comment from Jonathan Dieter on 2012-12-14 01:44:55 EST --- This bug still exists in kernel-3.6.7-5.fc18.x86_64. Typing echo -n rescan > /sys/devices/platform/i8042/serio1/drvctl fixes the problem until the next suspend/resume cycle. --- Additional comment from Dennis Burdick on 2012-12-20 10:44:29 EST --- Still exists in... Linux donna 3.6.10-2.fc17.x86_64 #1 SMP Tue Dec 11 18:07:34 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux --- Additional comment from Fedora End Of Life on 2013-01-16 09:33:05 EST --- This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 WONTFIX if it remains open with a Fedora 'version' of '16'. 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 prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 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 to click on "Clone This Bug" and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping --- Additional comment from Dennis Burdick on 2013-01-18 15:46:11 EST --- Still exists in... Fedora release 18 (Spherical Cow) Linux donna 3.7.2-201.fc18.x86_64 #1 SMP Fri Jan 11 22:16:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Not trying to push, but it has been a number of major releases without a peep. I know your busy, but any ideas?
Building on Jonathan Dieter's solution, for those that don't want to wait for a real fix. I created a file called 00kbreset in /usr/lib64/pm-utils/sleep.d/ with the following content ... #!/bin/bash case "$1" in hibernate) ;; suspend) ;; thaw|resume) sleep 5 echo -n rescan > /sys/devices/platform/i8042/serio1/drvctl ;; *) echo "ERROR: used incorrectly." ;; esac Note 1: Make sure you chmod +x 00kbreset. Note 2: I am using 64 bit. If you are using 32 bit, put the file in /usr/lib/pm-utils/sleep.d/ instead. This will rescan the device each time you resume/thaw. Works for me anyway. Best of luck. Thanks to Jonathan. Cheers, Dennis
Sorry folks. I thought that worked, but because Fedora move to systemd, so it doesn't use pm-utils to put the machine to sleep. Here is what did work for me. I created the following script in /usr/lib/systemd/system-sleep/kbreset.sh #!/bin/sh if [[ $1 == "post" ]] then DT=`date` echo "$DT - Caught post. Waking up from $2, about to run rescan for the keyboard reset." >> /var/log/kbreset.log echo -n rescan > /sys/devices/platform/i8042/serio1/drvctl fi Regards, Dennis
I need to use 2 commands to solve that: echo -n none > /sys/devices/platform/i8042/serio1/drvctl echo -n rescan > /sys/devices/platform/i8042/serio1/drvctl Just the "rescan" didn't solve the problem.
commit eeb065582a9618c1cf5b7154df7bae06aeb44636 Author: Eric Miao <eric.miao> Date: Tue Jun 4 09:30:55 2013 -0700 Input: synaptics - fix sync lost after resume on some laptops looks like it might fix this issue. That is in the 3.10 kernel and F18 should be rebased to 3.10 relatively soon.