Description of problem: On slow machines, gnome-power-manager (g-p-m) does not put display to sleep on 1st idle timeout, because by the time g-p-m register the idle time alarm for dim (gpm_idle_set_timeout_dim), the idle count is already more than the idle timeout. Eg. On my 700MHz laptop, by the time g-p-m in F12 registers 10 sec idle alarm, the idle count is already at 14 sec, so the 10 sec idle alarm never goes off, leaving the display always on, bad for LCD backlight. This happens when first login into gnome, and also on resume-from- suspend, when the CPU is busy. It was originally reported by James Ettle in bug508886 Comment#10 bug508886 Comment#14 Version-Release number of selected component (if applicable): gnome-power-manager-2.28.2-2.fc12.i686 How reproducible: always on a slow laptop (eg. 700MHz, 13 years old) never on a fast laptop (eg. 2.2GHz) rarely on a medium host (eg. 1.5GHz) always on a fast laptop that is intentionally slowed down by slower CPU clock and cpu huggers. Steps to Reproduce: 1. run gnome-power-preferences, "Put display to sleep when inactive for:" 5 minutes 2. logout of gnome. 3. login gnome, but be very careful not to touch any key/mouse after hitting enter for password. Actual results: On a slow machine the display was still on after 24 hours. On a fast machine the display went sleep after 5 minutes. Expected results: On the slow machine the display should also go sleep after 5 minutes. Additional info: 1. In gpm-idle.c, gpm_idle_set_timeout_dim(), I added this query { gint64 idle_counter = 0; idle_counter = egg_idletime_get_time(idle->priv->idletime); egg_debug ("xxx idle_counter=%lld", idle_counter); } egg_debug ("Setting dim idle timeout: %ds", timeout); On the fast machine it says - xxx idle_counter=2761 - Setting dim idle timeout: 10s On the slow machine it says - xxx idle_counter=14366 - Setting dim idle timeout: 10s Because the idle counter is already at 14.366 sec, the 10 sec idle alarm never fires. 2. On the fast machine, I did this to slow down intentionally: - change CPU clock to slowest available - run 20 cpu huggers (while (1) { i++; }) So the idle counter was at 11 sec when setting dim idle timeout. This did cause the issue to occur on the fast machine.
Work arounds: 1. after login gnome, hit a key to reset idle counter to 0; OR 2. change idle dim time for g-p-m k=/apps/gnome-power-manager/backlight/idle_dim_time gconftool-2 -s $k -t int 20 gconftool-2 -g $k On the 700MHz laptop this worked fine. The idle dim time was 30 sec in F11, changed to 10 sec in F12; does it cause any harm to change to 20? Probably not because g-p-m changes it on the fly anyway, from 10s->20s->40s->... depends on the idle time pattern (see bug566350 Comment #3). This does increase your chance of seeing bug566350.
Could you try gnome-power-manager from http://people.freedesktop.org/~hughsient/fedora/13/ (you'll have to rebuild the src.rpm for F12) as this should have fixed the race you describe. Thanks!
Richard, Thanks for super fast response! So I downloaded http://people.freedesktop.org/~hughsient/fedora/13/SRPMS/gnome-power-manager-2.29.92-1.256.20100321git.fc13.src.rpm and built it on F12; no luck. On the 700MHz lappy, with 10 sec backlight/idle_dim_time, I still see the same symptom: no display sleep after set time (eg. 5 minutes). I did see the idle count reduced to 13 sec (was 14 sec) when gpm_idle_set_timeout_dim() registered its 10 sec idle alarm, so I figured this would help in some border line case (eg. 10.5 sec -> 9.5 sec, thus below the 10 sec idle alarm). But I realized that, in general, we cannot guarantee that the idle count (eg. 14 sec on my slow lappy) will always be less than idle timeout (eg. 10 sec) when we are in gpm_idle_set_timeout_dim(); either the CPU is slow, or busy, or file system slow, or too many apps to start at login; all could cause this to occur. A possibility is that, in gpm_idle_set_timeout_dim(), query current idle count (by egg_idletime_get_time); if it's more than 'dim idle timeout', we know that dim idle alarm will never go off, thus we need to do something extra. But you know best what to do with g-p-m; I'm just providing some observation and suggestions. By any chance do you know why backlight/idle_dim_time was changed to 30 sec in F12 (was 10 sec in F11)? 30 sec was pretty sufficient even for my slow lappy, although one could argue it is not good enough for a really slow system.
Tim, I did your timing test as suggested in comment 29 of bug 508886. There may be something in this. I timed from login to the appearance of icons on the desktop. First, for the Clevo M720R (Intel T8100, 0.8-2.1 GHz, GMA965) Notes Time Display sleep? ------------------------------------------------- First login from cold 47s No Logged out then back in 6s Yes " " " " " 6s Yes Dropped the page cache 54s No Logged out then back in 6s Yes So the Clevo looks to be pretty consistent in this. (I really need to find out what I'm loading that's taking up all that time on login. Anyway...) Now for the HP zx5030EA (Intel Pentium 4, 2.8 GHz, ATI M9+) Notes Time Display sleep? ------------------------------------------------- First login from cold 46s No Logged out then back in 14s Yes " " " " " 17s Yes Rebooted, logged back in 28s No Logged out then back in 13s No* " " " " " 13s Yes Dropped the page cache 42s Yes Rebooted, logged back in 31s Yes * Might be due to cheap USB mouse. Both machines have xorg-x11-server-Xorg-1.7.6-1.fc12 and gnome-power-manager-2.28.3-1.fc12 (x86_64 and i686 versions, respectively).
Re: Comment #4 James, > There may be something in this. Agree! Looks like we are heading the right direction, with your detailed measurements. We can worry about the one outlier (13s No*) later. Thanks for your tips on dropping page cache; a good tool to know. To me the key signature of this bug is in Comment #0, Additional Info, #1 1. In gpm-idle.c, gpm_idle_set_timeout_dim(), I added this query [ print idle count when 'setting dim idle timeout' ] [ g-p-m put display to sleep properly if and only if (idle count < dim idle timeout) ] The idle alarm used by g-p-m is "positive transition" type, which fires when the counter *crosses* the threshold. If the idle count is already at 14 sec when g-p-m schedules 10 sec idle alarm, g-p-m will not receive the idle alarm. This is the reason why I believe we need to examine the idle count when setting dim idle timeout. This (print idle count) would be easy to do if you use rpmbuild; but if you don't have time, or don't feel like using rpmbuild, we can try another simple test, using workaround 2 in Comment #1: k=/apps/gnome-power-manager/backlight/idle_dim_time gconftool-2 -g $k # note down this number, so you can # restore it when done; should be 10. gconftool-2 -s $k -t int 60 gconftool-2 -g $k Let's change the timeout to 60 sec (*1), since your longest measurement in comment #4 is 54 sec. This way we guarantee the idle count (no more than 54 sec on your systems) will be less than the dim idle timeout (60 sec). If this (60 sec) makes a difference, we have more indirect evidence. *1: maybe 40 sec is good enough; but I suggest using 60, just in case. On my 2.5GHz lappy, I had Notes Time Display sleep? Idle count --------------------------------------------------------------- #1 First login from cold 26s Yes 6951 ms #2 Logged out then back in 8s Yes 1733 ms So in #1 above, g-p-m schedules the 10 sec idle alarm about 19 sec (=26s-6.9s) after I login. In your 54sec case, I imagined g-p-m reached the same point more than 19 sec after login, so the idle count could be 35 sec or less.
Hello, Sorry for the delay in getting back to this. I'm now testing with Fedora 13, the test machine has: gnome-power-manager-2.30.1-1.fc13.i686 xorg-x11-server-Xorg-1.8.0-12.fc13.i686 and with the default config manifests the no-sleep-on-1st-timeout bug. I then followed Tim's suggestion above and set backlight/idle_dim_time to 60s, and now the screen DOES sleep after the first timeout. (Repeated 3 times, issued a cache drop between logins.)
James, Thanks for getting back, and for your confirmation. I believe we have this issue thoroughly and properly analyzed, and the rest is for Richard to fix it in his way. Root cause: when g-p-m creates its idle timer (eg. 10 sec), the idle counter may have already exceeded the requested value (eg. 14 sec on a slow machine), thus the idle timer is never fired. See Comment #5, "key signature". Potential fix: Up to Richard. A possibility is to query idle counter before creating the idle timer; if the counter is too close to or larger than target (eg. desired threshold=10 sec, current counter=9 sec), extend the desired threshold to be one stop bigger than current counter + some margin (eg. 2 sec). Workaround: (see workaround 2 in Comment #1): k=/apps/gnome-power-manager/backlight/idle_dim_time gconftool-2 -g $k # note down this number, so you can # restore it when done; should be 10. gconftool-2 -s $k -t int 60 gconftool-2 -g $k
(In reply to comment #7) > Root cause: > when g-p-m creates its idle timer (eg. 10 sec), the idle counter may > have already exceeded the requested value (eg. 14 sec on a slow > machine), thus the idle timer is never fired. I would disagree on the point "slow" here: even the fastest machine I have here (which is by no means slow) isn't at a ready desktop 10 seconds from cold login. It's simply not possible with hard discs being what they are. So the fix should probably be to code up with a different set of assumptions or reset the idle timer as soon as g-p-m loads.
(In reply to comment #7) > Potential fix: > Up to Richard. A possibility is to query idle counter before > creating the idle timer; if the counter is too close to or larger > than target (eg. desired threshold=10 sec, current counter=9 sec), > extend the desired threshold to be one stop bigger than current > counter + some margin (eg. 2 sec). I think if a timeout is set in egg_idletime_alarm_set that has already passed, the alarm signal should be fired, and the NEGATIVE alarm setup rather than the POSITIVE one. Patches (and a self-check test) to do that would be very welcome, as my session boots under one second... :-) Richard.
James, Richard, Thanks for fast response! Re: Comment #8 James, OK, I'll take back that "slow" qualifier in "slow machine." Your systems definitely have fast CPUs. By any chance have you found out what is taking time during Gnome login? Could you run 'dstat' during your login to find out how your disk fare? You can run dstat by ssh'ing from another machine. Re: Comment #9 Richard, > Patches (and a self-check test) to do that would be very welcome, I'll work on that then, although I'll be slow at this time, to help organizing a Taiwanese American Conference (http://tacec.org) on Independence Day weekend. Another possibilities is to restore the timeout to be pre-F10 level, ie. 30->60->120->240..., instead of 10->20->40->80... It's much easier to implement. Would you recommend this approach? > as my session boots under one second... :-) You are discriminating against us who have slower machines :-) > I think if a timeout is set in egg_idletime_alarm_set that has > already passed, the alarm signal should be fired, and the NEGATIVE > alarm setup rather than the POSITIVE one. I agree that what you said *should* happen. But it is *not* happening when I tried it. The past-due timeout is simply ignored by Xext/sync.c. Is this what you see as well? If so, we need to work around the reality thrown at us by Xext/sync.c.
Created attachment 431338 [details] patch to adjust dim timeout when necessary. Richard, Please review the attached first cut for the proposed fix, as outlined in Comment #7. Here is the high level view of the fix. - in gpm_idle_set_timeout_dim(), before setting the timeout using egg_idletime_alarm_set(), we should check the current idle time by idle_time_in_msec = egg_idletime_get_time (idle->priv->idletime); - if the requested timeout is less than idle_time, double requested timeout, until timeout is larger than idle time. The fix is simple enough that I don't have a test case for it. Please suggest what to test if you see the need. Thanks.
Thanks Tim. Can you commit this to git master please.
Hi, Richard, Thanks for reviewing the change! How to I commit it to "git master?" I need to create my account somewhere, I guess; please indicate the process or guide to commit the change. Thanks!
Richard, Please advise how I can commit my changes into git master. Do I need a training or something?
I've committed this for you commit 740b86bb953d74838af1a2a6a333081a4fc14d2e Author: Tim Liim <tim.liim> Date: Wed Aug 4 09:46:20 2010 +0100 Adjust dim timeout when necessary On slow machines, or machines that have lots to load duing login, the current idle time could be bigger than the requested timeout. In this case the scheduled idle timeout will never fire, unless some user activity (keyboard, mouse) resets the current idle time. Instead of relying on user activity to correct this issue, we need to adjust timeout, as related to current idle time, so the idle timeout will fire as designed. Signed-off-by: Richard Hughes <richard>
Richard, Thanks!
Any thoughts on when a build with this patch will be in Koji?
I'm aiming to do a release at the end of this week.
Hmm... what happened to the release? And is there any schedule for this fix getting into F13 updates-testing, or is it in the 1.9 series X server (do the F14 packages play nicely on F13)?
(In reply to comment #19) > Hmm... what happened to the release? It's in F14. > And is there any schedule for this fix > getting into F13 updates-testing When I've got enough fixes in the gnome stable branch I'll do an upstream release and push it to distros. This will probably happen at the start of October.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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
Change 'Version' from F12 to F14; in Comment #20, Richard said > It's in F14.
Verified in F14, gnome-power-manager-2.32.0-3.fc14.x86_64. Will close this bug now, in my capacity as the bug reporter. Richard, Thanks! For reviewing and carrying the change for me. James, Could you also check if this also works for you in F14?
*** Bug 551077 has been marked as a duplicate of this bug. ***
> James, > Could you also check if this also works for you in F14? Yep, seems to be fixed for me. (Well, out of one test... I'll re-open if I notice anything out of order.)
James, Good to know it worked for you, 1 out of 1 try. Let us know if this issue is seen again. Cheers!