Red Hat Bugzilla – Bug 465444
Gnome Power Manager applet very slow on battery power in Beta 10 LiveCD i686
Last modified: 2013-01-09 23:49:41 EST
Description of problem:
Power Manager applet takes over a minute to refresh after removing power cable or booting up on battery power. It also seems to stall the shutdown process for over a minute
Version-Release number of selected component (if applicable):
Remove power cable from laptop while in a LiveCD session (Fedora Beta 10 i686), wait for Power Manager applet to refresh.
Steps to Reproduce:
1. Boot up LiveCD on ac power, then remove the power cable, wait for Power Manager applet to refresh.
2. Boot the LiveCD on battery power, desktop init is delayed by over a minute.
3. Select shutdown from the system menu while on battery power, system stalls for over a minute
Stalled system or un-responsive power manager applet for over a minute
Quick refresh of Power Manager applet to indicate battery power is being used
Additional info: Tested on Acer Aspire One, Asus EeePC 701, Dell Inspiron 1520
Sorry, this problem may have been partly due to my peculiar persistence overlay, I have tried with a clean Beta 10 LiveCD and the problem seems to be fixed on all laptops except on the Acer Aspire One.
So maybe this bug should be reclassified as Acer Aspire One specific - unless anyone reports the behaviour on another laptop.
My laptop is a "Terra Mobile 6000", its a Core 2 Duo Notebook with 1GB RAM, and on switch from AC to Battery, gnome-power-manager behaves very strangely!
47.4% MEM 0:50.08 CPU gnome-power-manager
So it takes nearly 500MB RAM...looks like some kind of memory leak!
Version is: gnome-power-manager.i386 2.24.0-6.fc10
Seeing this behavior on an Acer Aspire One as well.
Plugging / Unplugging power takes about a minute for gnome-power-manager to notice. Sometimes longer than a minute; sometimes less. Screen brightness changes right away however.
Additionally, for the minute or so that gnome-power-manager is 'stuck', the after-image of what was behind the screen brightness OnScreenDisplay remains onscreen, blocking whichever app you're using. I'll attach a screenshot, since I can reproduce this every time.
Created attachment 324562 [details]
screenshot of my AAO desktop with OSD afterimage not going away
Created attachment 324563 [details]
killall gnome-power-manager ; gnome-power-manager --verbose --no-daemon | tee gpm.log
when running "gnome-power-manager --verbose --no-daemon" the first time, before power is removed, it still takes about a minute for the applet to show up and for logging to continue. After power is unplugged, it's unresponsive yet again, as can be seen in the gaps in the attached log output.
TI:23:16:24 TH:0x9d1d628 FI:gpm-brightness-xrandr.c FN:gpm_brightness_xrandr_output_set,322
- percent=50, absolute=7812
TI:23:16:24 TH:0x9d1d628 FI:gpm-brightness-xrandr.c FN:gpm_brightness_xrandr_output_set,324
- hard value=15625, min=0, max=15625
TI:23:17:52 TH:0x9d1d628 FI:gpm-backlight.c FN:gpm_backlight_brightness_evaluate_and_set,456
- emitting brightness-changed : 50
TI:23:17:52 TH:0x9d1d628 FI:gpm-profile.c FN:ac_adaptor_changed_cb,635
- on battery
The OSD after-image is a different bug, probably something to do with metacity or your graphics drivers, I don't really know.
What do you get when you do:
and then unplug and plug? Do you get a delay there?
Created attachment 324644 [details]
lshal -m output for a plug/unplug cycle
No apparent delays from lshal -m output. OSD remains while it logs battery updates.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
lshal -m is responding instantly on my machine as well. But now as well i've got this sticky popup, that is staying there for approx. 30 sec. Also at this time gnome-power-manager sucks 5-6% CPU usage.
But it's approx. the same amount of time it stucks, than the brightness control applet. So does the gonme-power-manager try to adjust the screen brightness? YEP...I guess I found the bug...please try to go to properties -> On Battery Power -> and deactivate "reduce backlight brightness".
This is fixing it for me!
Yes, I also have problems like this on an HP Mini 1000, with Fedora 10. gpm will often chew up lots of CPU and be unresponsive. The applet doesn't repaint, and the OSD won't go away. Running strace on it shows it is stuck in a tight loop, reading and writing from fd 3, which is some socket.
Same problem here on a LG f1 express dual running fedora 10.
gpm is not responding and Xorg starts using about 30% of the CPU for a minute or so after plugging or unplugging the power,
I've deactivated "reduce backlight brightness" as advised above and the problem disappeared, except of one thing, the applet icon is not changing right away but after 20 seconds or so.
Created attachment 331451 [details]
Backtrace while gnome power manager is stuck
Same problem on machines with intel 945 GM. (OK with intel 965)
When the power state is changed, the brightness goes up (or down) so slowly.
I can see that, by repeating "xrandr --prop", the value of BACKLIGHT is increasing (or decreasing) gradually.
By "xrandr --output LVDS --set BACKLIGHT <number>", the brightness changes quickly.
The version of gpm is 2.24.3-1.fc10.
I've merged this into 2-24:
2009-02-12 Richard Hughes <email@example.com>
* src/gpm-brightness-xrandr.c: (gpm_brightness_xrandr_output_set):
Don't step through each brightness state when we fade modes, some
devices using XRandR have an insane number of steps. Use the step
value we calculated for the _up and _down logic.
I'll do a new package tonight or tomorrow.
I've installed the new package and now it's working great, thanks.
There's another problem on my machine with an intel 945 GM card. The Xrandr can't change the BACKLIGHT property and therefore the brightness isn't changing, but that doesn't belong to here.
Fixed on my machine with i945 GM, thank you.