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 effecting 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.

$ gnome-power-bugreport.sh

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.

Getting info from HAL

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

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 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 effect how it behaves. In order to understand those it is useful to dump all of the GNOME Power Management related settings:

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

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

$ gconftool --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 --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 --recursive-list /apps/gnome-power-manager > gpm.gconf.values.txt
$ gconftool --recursive-unset /apps/gnome-power-manager
$ gconftool --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

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 > 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.

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. [wiki:Bugs/Upstream/GNOME 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

• [https://wiki.ubuntu.com/DebuggingACPI DebuggingACPI]

CategoryBugSquad CategoryDebugging