Red Hat Bugzilla – Full Text Bug Listing
|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-manager||Assignee:||Richard Hughes <richard>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||10||CC:||adam, davidz, dcantrell, farrellj, rhughes, richard, Sascha.Zorn, theholyettlz, TheNorthFace, tsutomu|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-04-15 11:53:40 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description J Gallagher 2008-10-03 07:08:48 EDT
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 07:23:36 EDT
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 07:37:45 EDT
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-24 22:48:47 EST
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-24 22:50:36 EST
Created attachment 324562 [details] screenshot of my AAO desktop with OSD afterimage not going away
Comment 5 Jason Farrell 2008-11-24 23:19:22 EST
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-24 23:22:19 EST
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 08:48:19 EST
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 13:29:37 EST
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-25 22:30:48 EST
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 05:17:52 EST
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-04 20:08:14 EST
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 08:11:47 EST
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 14:15:17 EST
Created attachment 331451 [details] Backtrace while gnome power manager is stuck
Comment 14 Tsutomu Hiroshima 2009-02-11 21:14:41 EST
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 06:55:51 EST
I've merged this into 2-24: 2009-02-12 Richard Hughes <firstname.lastname@example.org> * 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 16 Richard Hughes 2009-02-12 08:03:02 EST
Comment 17 thenorthface 2009-02-13 07:46:59 EST
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-22 22:07:41 EST
Fixed on my machine with i945 GM, thank you.