Ubuntu Wiki

Introduction

Bugs relating to GNOME Power Manager (g-p-m) 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. Subsystem bugs: g-p-m is mostly a messenger of events happening well below the user-space (HAL, upower, pm-utils, kernel, graphics). Look through this webpage to learn how to look at the information that g-p-m is getting to see if that information is correct.

How to file

When filing bugs for g-p-m, the standard procedure is important. Use

ubuntu-bug gnome-power-manager

to file a new bug and

apport-collect BUGNUMBER

to attach information to an old report. The most important extra information to include in the bug description is your hardware. Please include an exact model number, such as "HP Pavilion dv1629us".

Also note that it's OK to report power-related bugs against g-p-m, but bug handlers typically reassign the report to a different underlying package.

Bug tags

No bug tags are used specifically for g-p-m, but please see Bugs/Tags for general tags that can be helpful.

Debugging procedure

The apport information includes output from /usr/share/gnome-power-manager/gnome-power-bugreport, a handy script that queries basic information about the system and the batteries installed, and from upower (formerly devicekit-power). Using this information and the bug description, try to consider which parts of the system are affecting the bug. For example,

• Problems with battery percentage or remaining time are usually bad data from upower (10.04), devicekit-power (9.10), or hal (9.04-).

• Problems with screen brightness (particularly function keys) are usually lack of support in the kernel (linux) or problems with key identification in udev.

Note that HAL has been deprecated since Ubuntu 9.10 (Karmic).

Monitoring Power Events

If the system is running HAL for power management (Ubuntu 9.04 and before), use

$ lshal -m > lshal.log.txt

to capture a log of HAL events. You might think this will produce a lot of unnecessary events, but most HAL events end up being power-related. After running this, attach lshal.log.txt to the bugreport.

If the system is running DeviceKit-power (9.10) or upower (10.04+), use

$ upower --monitor-detail > upower.log.txt

to capture the log, which is much nicer than HAL. (Replace upower with devkit-power in Ubuntu 9.10.)

Monitoring D-Bus Events

In general, the D-Bus events should mimic those from the other components, but g-p-m relies on D-Bus for most events so monitoring these events can be another point for debugging.

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 g-p-m (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'"

Please include the related D-Bus events as an attachment to the bug report.

Querying Battery Info

Under HAL (9.04 and before)

To get a list of all the batteries in the 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

Under upower and DeviceKit-power (9.10+)

Battery information can be take directly from upower using the following command:

$ upower --dump

(As before, replace with upower with devkit-power in 9.10.) The output of this command is automatically included in apport bug reports, but dumps from various states (unplugged, plugged in, critical battery) may help in diagnosing a problem.

Sending Direct Commands to HAL

Warning: HAL is deprecated since Ubuntu 9.10 so these commands may not work properly in recent versions of Ubuntu!

If g-p-m is having trouble shutting down, hibernating, or suspending, you can send commands directly to HAL to ensure that g-p-m is not getting in the way. (Copy+paste is recommended.)

Note: These should only be used for debugging. Do not use them during regular operation of your computer.

Configuration Settings

There are many settings that can affect how g-p-m 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

You can pipe the output to a file to attach it to a bug report:

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

Resetting to Defaults

In case a configuration option is causing the issue, you can set also all of your g-p-m settings back to their default state:

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

$ 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 g-p-m 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.

Getting info from g-p-m

GNOME Power Manager also has its own debugging mode that can be used to see what it is thinking internally. This is useful for particularly puzzling bugs.

Warning: When doing this it's recommended that you turn off session saving or doing it on a clean login or as another user on your system.

To get the debugging information from g-p-m, execute the following command:

killall gnome-power-manager && gnome-power-manager --verbose 2>&1 | tee ~/gpm.log

This kills gnome-power-manager and re-executes it in verbose mode, saving the log file gpm.log to your home directory. Please attach this file to the report.

The most useful things in this log are usually the values that g-p-m 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 trying to highlight the interesting parts before attaching is useful.

Finding out why suspend or hibernate aren't offered

Warning: This section is out-of-date on Ubuntu 10.04.

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

If g-p-m 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.

How to Triage

When looking at g-p-m bugs, the most important thing to diagnose is whether this is a g-p-m bug or not. In most cases people are filling the bugs against g-p-m because that is where they see it happening, but it really isn't a g-p-m 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 g-p-m. If g-p-m 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 g-p-m 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 g-p-m 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

• Kernel/Debugging/Backlight for backlight issues

• GNOME Power Manager Debugging for upstream reports

CategoryBugSquad CategoryDebugging