Red Hat Bugzilla – Bug 447138
Session powersave causing input delays
Last modified: 2009-07-14 11:46:44 EDT
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 188.8.131.52-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 184.108.40.206-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
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Don't touch keyboard or mouse for one minute
2. Jiggle keyboard or mouse
A 5-10 second delay occurs before the mouse pointer will move or an application
will accept input from the keyboard
Keyboard and mouse should respond immediately
Behaviour present on a Dell Inspiron 9300, with NVidia graphics card, Pentium M
processor, and Centrino chipset.
Here is some additional system information:
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
1600000 1333000 1067000 800000
*** 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.
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]
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 220.127.116.11-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
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 18.104.22.168-30.fc9.i686
Confirmed still present in updated f9 kernel 22.214.171.124-55.fc9.i686
Confirmed still present in updated f9 kernel 126.96.36.199-97.fc9.i686
Confirmed still present in updated f9 kernel 188.8.131.52-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.
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 184.108.40.206-29.fc9.i686
Here's to hoping.
Workaround found by disabling dimming in gnome-power-preferences (both AC and battery):
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:
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.