kde-guidance-power-manager changes CPU beahvior to "Performance" after suspend

Bug #149128 reported by Luke12
10
Affects Status Importance Assigned to Milestone
kde-guidance (Ubuntu)
Invalid
Undecided
Luka Renko

Bug Description

Binary package hint: kde-guidance-powermanager

In Kubuntu, whenever my laptop exits sunspension, the CPU behavior changes to Performance, even if the settings for the current situation (battery/mains powered) remain the same. This happens consistently after each suspension. The behavior can still successfully be changed manually from the applet - it seems simply that the program believes it has to change the CPU behavior after suspension, not that it stops working.

Revision history for this message
Luka Renko (lure) wrote :

What HW do you use (please attach dmesg output)?
Do you suspend to ram or disk (hibernate)? Does it behave the same for both operations?

Can you provide output of the following command before and after suspend:
cat /sys/devices/system/cpu/*/cpufreq/scaling_governor

Changed in kde-guidance:
assignee: nobody → lure
status: New → Incomplete
Revision history for this message
pauls (paulatgm) wrote :

I also have this on hardy alpha 3 updated to 1/14/08. Before suspend:

paul :~$ cat /sys/devices/system/cpu/*/cpufreq/scaling_governor
powersave
powersave

after resume from suspend:

paul :~$ cat /sys/devices/system/cpu/*/cpufreq/scaling_governor
performance
performance

This problem also happens on hibernate / resume.

I also have another problem that the menu on kde-guidance does nothing when I hit suspend. To suspend, I have to use konsole and enter "sudo pm-suspend". Hibernate does initiate and resume from the menu on kde-guidance.

I also have a problem with the kde logout menu selection for suspend. It takes the laptop down, but I cannot resume. I have to power off/on.

This was working ok on gutsy, although suspend performance on gutsy is poor .. usually reboots after 2nd suspend. I upgraded to hardy to see if it's any better.

regards,

Revision history for this message
pauls (paulatgm) wrote :

After upgrading to kernel 2.6.24-4, this directory no longer exists and kde-guidance does not show anything for cpu usage. Not sure what this means, except that it needs fixing in hardy.

paul :~$ cat /sys/devices/system/cpu/*/cpufreq/scaling_governor
cat: /sys/devices/system/cpu/*/cpufreq/scaling_governor: No such file or directory

Revision history for this message
Erik Andrén (erik-andren) wrote :

I can confirm this bug, on Hardy alpha 2.6.24-4 amd64 but using gnome.
This leads me to think that this might be a kernel issue and not kde-guidance-power-manager or gnome-power-manager-related.

I can reproduce the issue both on s3 and s4.

Revision history for this message
Wouter Deconinck (wdconinc) wrote :

I can reproduce the problems described above:
- suspend from guidance-power-manager in KDE does not work (for work-around see below), but does work from the lock/logout buttons applet
- resume brings the laptop back up in performance mode when using 2.6.24-4 on x86, but brings it back in ondemand mode (as expected) when using 2.6.24-5 although then guidance-power-manager doesn't show the cpu usage anymore (although the sysfs interfaces are fine)

The first problem (suspend using guidance-power-manager) can be 'solved' by disabling HAL and DBUS communication in /usr/share/python-support/kde-guidance-powermanager/powermanage.py by changing:

# Send suspend / hibernate commands to HAL or use Sx_COMMANDS
SUSPEND_USE_HAL = False

# Command to initiate suspend-to-disk when not using HAL
S4_COMMAND = "sudo /usr/sbin/pm-hibernate"
# Command to initiate suspend-to-ram when not using HAL
S3_COMMAND = "sudo /usr/sbin/pm-suspend"

Then run sudo update-python-modules after these changes. Add the following lines to /etc/sudoers:

User_Alias USERS = <usernames>
Cmnd_Alias SUSPEND = /usr/sbin/pm-hibernate, /usr/sbin/pm-suspend
USERS ALL = NOPASSWD: SUSPEND

powermanage.py tries to connect to HAL using DBUS at org.freedesktop.Hal.Device.SystemPowerManagement. This seems to fail (although support for suspend/hibernate using HAL is correctly determined at udi /org/freedesktop/Hal/devices/computer and key .power_management.can_suspend_to_ram). I tried to investigate with kdbus, but also there the connection seems to fail... Could this be a DBUS problem?

I have no experience with HAL, DBUS or Python, but I can give more info if you tell me how to get it.

Revision history for this message
Andreas Wenning (andreas-wenning) wrote :

The problem with suspend not working is already fixed in Hardy, kde-guidance-powermanager 0.8.0svn20080103-0ubuntu7

Does the problem with not returning to the correct CPU behaviour exist if you suspend using the guidance-powermanager applet? Or does it only occur if you suspend from eg. the logout menu?

Revision history for this message
Harald Sitter (apachelogger) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Changed in kde-guidance:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.