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 include lshal.log.txt to the bug report.

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.

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 include 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 system 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'.

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

GNOME Bugzilla Note: need link

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

-- Two batteries from HAL

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

CategoryBugSquad CategoryDebugging