Bug 447138 - Session powersave causing input delays
Session powersave causing input delays
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-18 02:58 EDT by Steve Castellotti
Modified: 2009-07-14 11:46 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 11:46:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot of gnome power history (71.14 KB, image/jpeg)
2008-05-18 02:58 EDT, Steve Castellotti
no flags Details

  None (edit)
Description Steve Castellotti 2008-05-18 02:58:34 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 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)
Comment 1 Steve Castellotti 2008-05-18 02:58:34 EDT
Created attachment 305834 [details]
screenshot of gnome power history
Comment 2 Dave Jones 2008-05-18 13:55:20 EDT
as a hunch.. can you try booting with nohz=off ?
Comment 3 Steve Castellotti 2008-05-18 14:54:02 EDT
Just gave it a shot. Sorry, no luck - problem persists with that setting.
Comment 4 Steve Castellotti 2008-05-20 12:48:43 EDT
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.
Comment 5 Steve Castellotti 2008-05-21 11:44:25 EDT
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.
Comment 6 Steve Castellotti 2008-06-09 02:23:19 EDT
Confirmed to still occur with updated f9 kernel 2.6.25.4-30.fc9.i686
Comment 7 Steve Castellotti 2008-06-13 22:58:14 EDT
Confirmed still present in updated f9 kernel 2.6.25.6-55.fc9.i686
Comment 8 Steve Castellotti 2008-07-27 02:46:28 EDT
Confirmed still present in updated f9 kernel 2.6.25.11-97.fc9.i686
Comment 9 Steve Castellotti 2008-08-17 17:20:41 EDT
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.
Comment 10 Steve Castellotti 2008-09-17 18:18:46 EDT
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.
Comment 11 Steve Castellotti 2008-09-22 02:26:38 EDT
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.
Comment 12 Bug Zapper 2009-06-09 20:57:16 EDT
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
Comment 13 Bug Zapper 2009-07-14 11:46:44 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.