Introduction

Bugs relating to GNOME Power Manager (GPM) typically fall into 2 categories:

1. User interface bugs - require a detailed description of the issue, steps to reproduce and screen captures where appropriate.
2. HAL, pm-utils, kernel, graphics bugs - GPM is mostly a messenger of events happening well below the user-space. Look through this webpage to learn how to look at the information that GPM is getting to see if that information is correct.

How to file

When filing bugs for GPM, it is important to think about which parts of the system are affecting the bug. Different information for each is useful.

Getting hardware information

There is a handy little script that'll query all of your hardware information for you. If you're submitting a bug regarding power management it's very likely to be hardware related.

$ /usr/share/gnome-power-manager/gnome-power-bugreport

This provides basic information about your system and some information on the batteries that are installed. You can also look through the following pages to find more specific information regarding your problem.

This script is automatically included in Apport bug reports. If a bug is missing this information, it can be added by running:

$ apport-collect BUGNUMBER

or by reporting a bug using:

$ ubuntu-bug gnome-power-manager

The Apport hook will add the log file from "usr/share/gnome-power-manager/gnome-power-bugreport" and the output from "devkit-power -d".

Getting info from HAL (HAL will be deprecated in Karmic)

To get a list of all the batteries in your system you can use HAL:

$ hal-find-by-capability --capability "battery"

You can then discover the settings of each of the batteries including information like model numbers by doing this:

$ hal-find-by-capability --capability "battery" | xargs -n 1 hal-device

This provides all the possible information, but sometimes it is easier to look for specific information through the command line. For instance, if you wanted to look and see if the batteries are being seen as recharging:

$ hal-find-by-capability --capability "battery" | xargs -t -n 1 hal-get-property --key battery.rechargeable.is_charging --udi

If your problem is related to events that are happening over time, or by doing something specific, you should include a list of all the HAL events that are happening over that time. As it turns out, the majority of the time almost all HAL events are power related

$ lshal -m

To test this, if you have a laptop, you can run this command and plug and unplug your power adapter. You should get a bunch of messages. To save this into a log you can do this:

$ lshal -m > lshal.log.txt

Please attach lshal.log.txt to the bug report.

Sending commands to HAL (HAL will be depricated in Karmic)

GNOME Power Manager uses HAL to implement the lower levels of power management. You can send commands directly to HAL to insure that GPM is not getting in the way. These command strings are long, I'd recommend cutting and pasting, every character is important.

Note: These should only be used for debugging. These work around GNOME Power Manager which provides other functions to your desktop in handling these events. It is unwise to use them during regular operation of your computer.

Getting info from DeviceKit-power (for Karmic and higher)

Battery information can be take directly from devicekit-power using the following command:

$ devkit-power -d

The output of this command is automatically included in Apport bug reports. If a bug is missing this information, it can be added by running:

$ apport-collect BUGNUMBER

or by reporting a bug using:

$ ubuntu-bug gnome-power-manager

Additionally, the output of "usr/share/gnome-power-manager/gnome-power-bugreport" also includes the output from "devkit-power -d" for versions of gnome-power-manager > 2.27.2.

Getting DBUS info

Much of the functionality available in GPM is available through DBUS. So that means that we can use DBUS to watch the events going across the bus. Here is the way to look for power related events:

$ dbus-monitor --session "type='signal',interface='org.freedesktop.PowerManagement'"

These should be events like the power being plugged in or out. Also things like low battery notification. It is important that these events are being generated.

Also, if the backlight is being controlled by GPM (in some setups there are work arounds via various programs) backlight events should also be sent across the bus. Here is how to watch those:

$ dbus-monitor --session "type='signal',interface='org.freedesktop.PowerManagement.Backlight'"

In general, the DBUS events should mimic those from the other components, but it is another point for debugging to try and figure out what is going on.

Please include the related DBUS events as an attachment to the bug report.

Getting GConf values

GNOME Power manager is built so that you can customize it to your individual likes, desires and requirements. This means that there are many settings that can affect how it behaves. In order to understand those it is useful to dump all of the GNOME Power Management related settings:

$ gconftool-2 --recursive-list /apps/gnome-power-manager

This list is likely to be rather long, so you should save it to a file:

$ gconftool-2 --recursive-list /apps/gnome-power-manager > gpm.gconf.values.txt

Please attach this file on a bug report.

If you would like to set all of your GNOME Power Manager settings back to their default state you can do so also using the GConf tool:

$ gconftool-2 --recursive-unset /apps/gnome-power-manager

If this fixes your problem it is useful to know which values changed. You can do this by executing a diff on the two captures. Something similar to this:

$ gconftool-2 --recursive-list /apps/gnome-power-manager > gpm.gconf.values.txt
$ gconftool-2 --recursive-unset /apps/gnome-power-manager
$ gconftool-2 --recursive-list /apps/gnome-power-manager > gpm.gconf.default.values.txt
$ diff -u gpm.gconf.values.txt gpm.gconf.default.values.txt

This will tell you which values were customized before they were unset.

NOTE: Long time Ubuntu users should not be surprised if this unsets a bunch of values. Over time GPM has stopped using several values that may be set in your system. This is done on purpose in case you use multiple systems with different versions of Ubuntu. Unsetting won't cause a problem in this case as on all systems they'll be reset to default.

Sending commands to GPM

NOTE: THIS SECTION IS DEPRECATED IN KARMIC Sometimes the problem seems to be that GNOME Power Manager can't handle an event correctly. This could be a problem with the UI, or it could be that the hardware/drivers can't handle the event properly. To send straight through DBUS you can use this command:

$ gnome-power-cmd.sh reboot

The other available commands are: 'suspend', 'shutdown' and 'hibernate'.

Getting info from GPM

GPM also has it's own debugging mode that can be used to see what it is thinking internally. This is useful for particularly puzzling bugs.

NOTE: When doing this it's recommended that you turn off session saving. You can mess up your session in difficult to debug ways. I'd recommend doing it on a clean login or as another user on your system. To disable automatic session saving go to System->Preferences->Sessions and select the "Session Options" tab.

First you need to kill the GPM started by your session manager:

$ killall gnome-power-manager

Then you can start GPM with verbose mode and in the terminal:

$ gnome-power-manager --verbose --no-daemon

This is likely to generate more data than your scrollback buffer in your terminal. So probably a more useful command is:

$ gnome-power-manager --verbose --no-daemon 2>&1 | tee gpm.debug.log.txt

The most useful things in this log are usually the values that GPM thinks that things are. You can look through to see if they match your expectations and what you've set them to by other means. The analysis is the trickiest part, so taking some time to look through it before attaching is useful. Take a guess.

Finding out why suspend or hibernate aren't offered

Also see http://live.gnome.org/GnomePowerManager/FAQ#head-5d4d7bb306ca154c956e3ef69dae036942f6cf40

If GNOME doesn't offer you a suspend or hibernate option then you can use the following commands to narrow down why. The commands are shown for debugging suspend, for hibernate just replace all occurrences of "suspend" with "hibernate".

dbus-send --session --print-reply --dest="org.freedesktop.PowerManagement" --type=method_call --reply-timeout=6000 /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.CanSuspend

If this says "true" then gnome-power-manager thinks you should be able to suspend and something is just not displaying the option. If it says "false" then we need to work out why it thinks you can't.

gconftool-2 -g /apps/gnome-power-manager/general/can_suspend

If this returns "false" then suspend is disallowed by gconf. If this wasn't set by you then investigate whether there have been any schema changes.

polkit-auth | grep power-management.suspend

If this doesn't return anything then you don't have policykit authorization to suspend. This is either a local policy decision, or could be a problem with policykit, or more likely consolekit on your system.

hal-device | grep power_management.can_suspend

If this returns "false" then hal is telling g-p-m that your computer is not capable of suspending. If it returns false then

pm-is-supported --suspend || echo "Not supported"

will probably tell you that suspend isn't supported. If that is the case then you need to investigate why pm-utils thinks you can't suspend.

Bug tags

Bug tags specific to the package or area should be included here for reporters so they can tag their bug report. It will also be useful for triagers. The Bugs/Tags wiki page should then be modified to include these tags.

Debugging procedure

In depth debugging procedures for this particular package or subsystem. This usually is information about the log files to gather and what to look for in them.

How to Triage

When looking at GPM bugs, the most important thing to diagnose is whether this is a GPM bug or not. In most cases people are filling the bugs against GPM because that is where they see it happening, but it really isn't a GPM bug.

In almost all cases a suspend/resume problem is a kernel, graphics driver or pm-utils bug. Assign to pm-utils if unsure. So, it will probably need to be reassigned. But, that doesn't mean while you're looking at it you can't ask for more information! A good way to test if it was a specific kernel or xserver version is to downgrade to the one used in a previous release. While this isn't for beginning users, it does provide for a significant amount of information for the bug being passed on. This is especially pertenent if the user reports it working in a previous version of Ubuntu.

HAL provides a significant amount of information to GPM. If GPM seems to be reporting the state of something incorrectly, it's important to check to see if HAL is reporting it correctly. If HAL isn't either, the bug becomes a HAL bug.

The most common types of bugs that "stick" with GPM are UI bugs. In these cases it's important to attach screenshots, and if the user is suggesting changes, mockups.

Stock Reply

A stock reply to be used for initial bug reports basically asking for the stuff in "How to file". The Bugs/Responses page should include this reply.

How to Forward

This project uses GNOME Bugzilla. Instructions on filing bugs to GNOME Bugzilla.

Known bugs

Description of known bug reports that may receive duplicates and how to recognise them. This information should be obtained by looking for bugs tagged as 'metabug'.

Open

Reassigned

Closed

Non-bugs

At the GPM level it is almost impossible to tell whether a problem is a hardware one or a lower level software one. It is more reasonable to assign it down the stack than to try and figure out a hardware issue.

Also see

• DebuggingProcedures

• DebuggingACPI

• GNOME Power Manager Debugging for upstream reports

CategoryBugSquad CategoryDebugging