Bug 465444

Summary: Gnome Power Manager applet very slow on battery power in Beta 10 LiveCD i686
Product: [Fedora] Fedora Reporter: J Gallagher <jbgallagher2000>
Component: gnome-power-managerAssignee: Richard Hughes <richard>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 10CC: adam, davidz, dcantrell, farrellj, james, rhughes, richard, Sascha.Zorn, TheNorthFace, tsutomu
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-15 15:53:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
screenshot of my AAO desktop with OSD afterimage not going away
none
killall gnome-power-manager ; gnome-power-manager --verbose --no-daemon | tee gpm.log
none
lshal -m output for a plug/unplug cycle
none
Backtrace while gnome power manager is stuck none

Description J Gallagher 2008-10-03 11:08:48 UTC
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):


How reproducible:
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
  
Actual results:
Stalled system or un-responsive power manager applet for over a minute


Expected results:
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

Comment 1 J Gallagher 2008-10-03 11:23:36 UTC
Update:

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.

Comment 2 Sascha Zorn 2008-10-20 11:37:45 UTC
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!

Currently:
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

Comment 3 Jason Farrell 2008-11-25 03:48:47 UTC
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.

Comment 4 Jason Farrell 2008-11-25 03:50:36 UTC
Created attachment 324562 [details]
screenshot of my AAO desktop with OSD afterimage not going away

Comment 5 Jason Farrell 2008-11-25 04:19:22 UTC
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.

Comment 6 Jason Farrell 2008-11-25 04:22:19 UTC
same pattern:

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

Comment 7 Richard Hughes 2008-11-25 13:48:19 UTC
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:

lshal -m

and then unplug and plug? Do you get a delay there?

Comment 8 Jason Farrell 2008-11-25 18:29:37 UTC
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.

Comment 9 Bug Zapper 2008-11-26 03:30:48 UTC
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 10 Sascha Zorn 2008-12-11 10:17:52 UTC
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!

Comment 11 Adam Goode 2009-02-05 01:08:14 UTC
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.

Comment 12 thenorthface 2009-02-09 13:11:47 UTC
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.

Comment 13 Adam Goode 2009-02-10 19:15:17 UTC
Created attachment 331451 [details]
Backtrace while gnome power manager is stuck

Comment 14 Tsutomu Hiroshima 2009-02-12 02:14:41 UTC
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.

Comment 15 Richard Hughes 2009-02-12 11:55:51 UTC
I've merged this into 2-24:

2009-02-12  Richard Hughes  <richard>

	* 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.
	Fixes #566095

I'll do a new package tonight or tomorrow.

Comment 17 thenorthface 2009-02-13 12:46:59 UTC
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.

Comment 18 Tsutomu Hiroshima 2009-02-23 03:07:41 UTC
Fixed on my machine with i945 GM, thank you.