Description of problem: After approximately one minute of inactivity, the keyboard and mouse will lock. Moving the mouse or pressing keys will result in a 5-10 second delay before they once again become responsive. By using this Gnome Power History component, there clearly appears an entry marking "Session powersave" at the moment this occurs. When the input devices finally re-activate, a "Session active" mark is made. I have attached a screenshot indicating this behaviour. I have searched online for indication of what "Session powersave" exactly refers to, but the details are not indicated in Gnome's Help for this component, and I could not find any history of forum discussions mentioning this issue. Items such as CPU Frequency scaling have no effect. Programs running on screen continue to do so even when input is "stalled." The only notable difference seems to be a brief 100% CPU spike during the end of the 5-10 second delay period, at the exact moment where responsiveness is returned. I can confirm this is an issue related to the kernel (or at least default settings for Fedora's kernel) as I experienced this same issue under Fedora 8. I know for absolute certain that kernel 2.6.23.1-49.fc8-i686 did *not* exhibit this behaviour, but later kernels did. (I'm not however positive if the very next version released was the first to exhibit this problem, or the second released, or third for that matter) After I first noticed the issue under Fedora 8 I tried many subsequent kernel updates, but all have since had the same problem. Rebooting back to the 2.6.23.1-49 kernel always fixed the issue. Upgrade from Fedora 8 to Fedora 9 was via a complete fresh re-installation, to ensure no "bad" settings were carried over. I would have reported the issue much earlier, however until now I've never been able to find a setting or utility which registered a change coinciding with the problem. Version-Release number of selected component (if applicable): kernel-2.6.25-14.fc9.i686 How reproducible: Every time Steps to Reproduce: 1. Don't touch keyboard or mouse for one minute 2. Jiggle keyboard or mouse Actual results: A 5-10 second delay occurs before the mouse pointer will move or an application will accept input from the keyboard Expected results: Keyboard and mouse should respond immediately Additional info: Behaviour present on a Dell Inspiron 9300, with NVidia graphics card, Pentium M processor, and Centrino chipset. Here is some additional system information: cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 2.00GHz stepping : 8 cpu MHz : 2000.000 cache size : 2048 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts est tm2 bogomips : 3993.19 clflush size : 64 fgrep -r '' /sys/devices/system/cpu/cpu0/cpufreq /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:800000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:2000000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:800000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:2000000 /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0 /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:ondemand /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:acpi-cpufreq /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:ondemand userspace performance /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsupported> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:2000000 1600000 1333000 1067000 800000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:800000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:800000 /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate_max:10000000 /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate_min:10000 /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate:20000 /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold:31 /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load:1 /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias:0 *** NOTE *** I ran a script which output the above every 15 seconds to a log file, and used that to diff settings at the time the system seemed "stalled" against "normal" operation and there was no difference. lspci 00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03) 00:01.0 PCI bridge: Intel Corporation Mobile 915GM/PM Express PCI Express Root Port (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3) 00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03) 00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 03) 00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) 01:00.0 VGA compatible controller: nVidia Corporation NV41.8 [GeForce Go 6800] (rev a2) 03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) 03:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b3) 03:01.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 08) 03:01.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 17) 03:03.0 Network controller: Intel Corporation PRO/Wireless 2915ABG Network Connection (rev 05)
Created attachment 305834 [details] screenshot of gnome power history
as a hunch.. can you try booting with nohz=off ?
Just gave it a shot. Sorry, no luck - problem persists with that setting.
Rolled back to 2.6.23.1-49.fc8 kernel (still running Fedora 9) Fixes the problem, like magic. Mouse and keyboard always instantly responsive, even after long delays of non-use. Checking gnome power history, there's still "Session powersave" and "Session active" markers appearing after a minute or so of inactivity and after touching the mouse/keyboard respectively.
Active Skype calls are dropped when Session powersave hits while running the F9 kernel. In order to keep connected the mouse needs to be stirred like a pot on a stove! Happy to provide any sort of information, test rawhide kernels, or explore other ways I might be able to help resolve this issue.
Confirmed to still occur with updated f9 kernel 2.6.25.4-30.fc9.i686
Confirmed still present in updated f9 kernel 2.6.25.6-55.fc9.i686
Confirmed still present in updated f9 kernel 2.6.25.11-97.fc9.i686
Confirmed still present in updated f9 kernel 2.6.25.14-108.fc9.i686 Doesn't look like anyone's interested in this one? I didn't think I'd be the only person affected. I've actually gone and had my motherboard completely replaced/serviced and confirmed this is not a hardware issue. This issue exists with every Fedora 9 kernel which I've ever tested. I'm having issues now in which I can't build new kernel drivers because F9 doesn't use the same GCC by default which was used to build the F8 kernel I still have to run. Once again I'm more than happy to provide any further information or perform and testing. Thanks.
The stage lies in total darkness as the curtains are drawn aside. A beam of light suddenly fires down, illuminating a single microphone stand. The silhouette of a figure, their face bathed in shadow, steps forward. Arms outstretched, they tug first on their right sleeve, then the left. The collar is adjusted and a step taken forward. <TAP> <TAP> <TAP> "IS THIS THING ON?" ... Issue confirmed to still occur with f9 kernel 2.6.26.3-29.fc9.i686 Here's to hoping.
Workaround found by disabling dimming in gnome-power-preferences (both AC and battery): http://webui.sourcelabs.com/fedora/issues/427697 Note that this isn't a gnome power issue, it is simply that a new kernel setting (since the original F8 kernel) is affected by a system call gnome power makes when it attempts to dim the screen. Seems like the issue is with the linux kernel, under settings specific to what Fedora is using in new kernels.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9'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 9 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 to the applicable version. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.