Bug 465444 - Gnome Power Manager applet very slow on battery power in Beta 10 LiveCD i686
Summary: Gnome Power Manager applet very slow on battery power in Beta 10 LiveCD i686
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-power-manager
Version: 10
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-03 11:08 UTC by J Gallagher
Modified: 2013-01-10 04:49 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-15 15:53:40 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
screenshot of my AAO desktop with OSD afterimage not going away (183.62 KB, image/png)
2008-11-25 03:50 UTC, Jason Farrell
no flags Details
killall gnome-power-manager ; gnome-power-manager --verbose --no-daemon | tee gpm.log (31.82 KB, text/plain)
2008-11-25 04:19 UTC, Jason Farrell
no flags Details
lshal -m output for a plug/unplug cycle (6.03 KB, text/plain)
2008-11-25 18:29 UTC, Jason Farrell
no flags Details
Backtrace while gnome power manager is stuck (5.40 KB, text/plain)
2009-02-10 19:15 UTC, Adam Goode
no flags Details

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.


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