Description of problem: After a resume from either a suspend to ram or suspend to disk, my keyboard fails to function. I find I can repair the problem by climbing under my desk and unplugging and re-plugging in my keyboard from the computer. I am not sure if it is important, but I use a kvm switch. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. Suspend my computer to disk or ram. 2. Resume 3. Focus the mouse on any window and attempt to type. Actual results: The keyboard fails to function until I disconnect it from the computer and reconnect this. I can do this one of two ways. I can unplug the keyboard from the kvm switch and then plug it back in. Or, I can unplug the kvm switch from the computer and plug it back in. Expected results: Keyboard should continue to function normally, as it does for other operating systems after a suspend and resume. Additional info:
Is it maybe enough to remove and load the kernel module for the usb keyboard? I do not know which one it is, but if you know, please mention it here, too.
I am not really sure. My best guess is the keyboard is loaded in the "dock" module. So I will create the following file, and see it it works: # cat >/etc/pm/config.d/defaults <<+ SUSPEND_MODULES="dock" RESUME_MODULES="dock" DISABLE_HIBERNATE="yes" DISABLE_SUSPEND="no" +
It looks like this solves the problem. I tried several times after creating the defaults file, and the keyboard functioned correctly each time. Since the same problem also sometimes occurs with a reboot, I also modified /etc/rc.d/rc.local to do the same thing. I guess this should be reclassified as a kernel bug, since obviously the problem is with the kernel module. Bill
BTW. Where is the documentation for pm-utils located. I figured out to use the /etc/pm/config.d/defaults file only by guessing.
This might be related to the KVM switch you are using, too. Maybe sometimes it doesn't forward every signal properly to/from the computer/keyboard. Have you tried it without the KVM switch and see if it works properly then? Read ya, Phil
Without the kvm switch it doesn't use a kernel module... But, I do know the kvm switch works properly. I use the same switch with Fedora6, RHEL5, Gentoo, Ubuntu, Windows, and MacOSX. Only Fedora 7 exhibits this problem. And Fedora 7 exhibits the problem on multiple computers. Reloading the module however, seems to work great for fixing. Modifying a couple of configuration files is much less painful than crawling under my desk regularly. Bill
For some reason, the reloading of the "dock" module stopped working, and I find myself regularly climbing under the computer again to unplug and replug my keyboard. However, I did discover another workaround. While the computer is resuming, I switch to a different computer on my KVM. Once resumed, I can switch back and use my keyboard normally. Because I have a dual monitor setup, I can monitor the resume progress by watching the second monitor. Since the keyboard doesn't actually stop responding until X11 is resumed, I suspect the problem is with the proprietary NVIDIA driver. Unfortunately, the regular driver does not support twinview, so I do not have a good way of taking this driver out to verify other than possibly a few test boots. Bill
I do not know, whether this works or will not crash the system, but maybe it also helps when you add the nvidia kernel module to SUSPEND_MODULES.
Hm, maybe the kernel masters can fix the dock module, to make it work better with suspend and resume.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'. 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 7'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 7 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 please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 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. Thank you for reporting this bug and we are sorry it could not be fixed.