Karmic Alpha 6: devicekit-power-daemon crash with SIGPIPE

[Chris B]

Binary package hint: devkit-power

Karmic Alpha 6
acpi, sys and proc filesystems all detect battery status, but devkit and g-p-m do not.

It appears as if the issue stems from devkit-power-daemon, and gnome-power-manager is just reflecting that lack of status.

$ devkit-power -d
Device: /org/freedesktop/DeviceKit/Power/devices/battery_BAT0
  native-path: (null)
  power supply: no
  updated: Thu Jan 1 07:30:00 1970 (1253640103 seconds ago)
  has history: no
  has statistics: no
  unknown

Device: /org/freedesktop/DeviceKit/Power/devices/line_power_AC0
  native-path: /sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/AC0
  power supply: yes
  updated: Wed Sep 23 01:21:42 2009 (1 seconds ago)
  has history: no
  has statistics: no
  line-power
    online: yes

Daemon:
  daemon-version: 011
  can-suspend: yes
  can-hibernate yes
  on-battery: no
  on-low-battery: no
  lid-is-closed: no
  lid-is-present: yes

ProblemType: Bug
Architecture: i386
Date: Wed Sep 23 01:13:13 2009
DistroRelease: Ubuntu 9.10
Package: gnome-power-manager 2.28.0-0ubuntu1
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-10.34-generic
SourcePackage: gnome-power-manager
Uname: Linux 2.6.31-10-generic i686

[Chris B (billington-chris)]

I tried running devkit-power-daemon from a console, producing the attached log.

sudo /usr/lib/devicekit-power/devkit-power-daemon 2>&1 | tee /tmp/dkp.log

The daemon appears to quit from this session by itself (crashes?) just after line 468 of dkp-device-supply.c , reading the battery status from /sys, and resetting the 'unknown' status counter. This happens the second time it passes the dkp-device_supply_refresh_battery function.

Booting the machine from the Jaunty LiveCD image produces working battery status via Hal, however.

[Chris B (billington-chris)]

initially wrongly assigned to gnome-power-manager

[Chris B (billington-chris)]

GDB backtrace for devicekit-power-daemon is attached. The daemon crashes with a SIGPIPE (broken pipe) error.

Could this be because of the negative value for 'Capacity granularity 2' contained in this machine's broken DSDT table in BIOS? Unfortunately, I can't fix this by overriding the DSDT, since the capability to do this in the initramfs is not present in the 2.6.31 kernel used in Karmic. I hope it will be added back.

chris@chris-laptop:~$ cat /proc/acpi/battery/BAT0/*
alarm: unsupported
present: yes
design capacity: 3200 mAh
last full capacity: 3360 mAh
battery technology: rechargeable
design voltage: 7400 mV
design capacity warning: 0 mAh
design capacity low: 0 mAh
capacity granularity 1: 0 mAh
capacity granularity 2: -1 mAh
model number: 2S1P
serial number:
battery type: LION
OEM info: ��������������������������������

present: yes
capacity state: ok
charging state: discharging
present rate: 1875 mA
remaining capacity: 1563 mAh
present voltage: 7341 mV

[Martin Pitt (pitti)]

Thanks for your report. I really doubt that it's due to the negative value, since (1) a SIGPIPE is very unlikey in this case, and (2) it crashes deep in D-BUS code which usually doesn't care about particular message values.

Unfortunately the stack trace isn't very clear. You seem to be able to reproduce this reliably, any chance you could install some debugging symbols and use gdb again? https://wiki.ubuntu.com/DebuggingProgramCrash describes how to set up the debug symbol repository. You'll need these packages:

  sudo apt-get install devicekit-power-dbgsym libdbus-1-3-dbgsym libdbus-glib-1-2-dbgsym libdevkit-power-gobject1-dbgsym libgudev-1.0-0-dbgsym libglib2.0-0-dbgsym

Thanks!

Or even easier, the dk-power backend crash should be caught by Apport, and you should get offered to file a bug about it. This will automatically get post-processed to get a fully symbolic stack trace.

[Chris B (billington-chris)]

Hi Martin,

Yes, this is an every-time crash: the daemon dies after first run and the
battery is not detected or stats collected.
I'll install the debugging symbols, and update the report.

For some reason, Apport did not catch the crash- I'll check whether it is
still disabled out-of-box on the Alpha.

Chris

On Fri, Oct 2, 2009 at 2:35 AM, Martin Pitt <email address hidden> wrote:

> Thanks for your report. I really doubt that it's due to the negative
> value, since (1) a SIGPIPE is very unlikey in this case, and (2) it
> crashes deep in D-BUS code which usually doesn't care about particular
> message values.
>
> Unfortunately the stack trace isn't very clear. You seem to be able to
> reproduce this reliably, any chance you could install some debugging
> symbols and use gdb again? https://wiki.ubuntu.com/DebuggingProgramCrash
> describes how to set up the debug symbol repository. You'll need these
> packages:
>
> sudo apt-get install devicekit-power-dbgsym libdbus-1-3-dbgsym
> libdbus-glib-1-2-dbgsym libdevkit-power-gobject1-dbgsym
> libgudev-1.0-0-dbgsym libglib2.0-0-dbgsym
>
> Thanks!
>
> Or even easier, the dk-power backend crash should be caught by Apport,
> and you should get offered to file a bug about it. This will
> automatically get post-processed to get a fully symbolic stack trace.
>
> ** Changed in: devicekit-power (Ubuntu)
> Status: New => Incomplete
>
> --
> Karmic Alpha 6: devicekit-power-daemon crash with SIGPIPE
> https://bugs.launchpad.net/bugs/434771
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “devicekit-power” package in Ubuntu: Incomplete
>
> Bug description:
> Binary package hint: devkit-power
>
> Karmic Alpha 6
> acpi, sys and proc filesystems all detect battery status, but devkit and
> g-p-m do not.
>
> It appears as if the issue stems from devkit-power-daemon, and
> gnome-power-manager is just reflecting that lack of status.
>
> $ devkit-power -d
> Device: /org/freedesktop/DeviceKit/Power/devices/battery_BAT0
> native-path: (null)
> power supply: no
> updated: Thu Jan 1 07:30:00 1970 (1253640103 seconds ago)
> has history: no
> has statistics: no
> unknown
>
> Device: /org/freedesktop/DeviceKit/Power/devices/line_power_AC0
> native-path:
> /sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/AC0
> power supply: yes
> updated: Wed Sep 23 01:21:42 2009 (1 seconds ago)
> has history: no
> has statistics: no
> line-power
> online: yes
>
> Daemon:
> daemon-version: 011
> can-suspend: yes
> can-hibernate yes
> on-battery: no
> on-low-battery: no
> lid-is-closed: no
> lid-is-present: yes
>
> ProblemType: Bug
> Architecture: i386
> Date: Wed Sep 23 01:13:13 2009
> DistroRelease: Ubuntu 9.10
> Package: gnome-power-manager 2.28.0-0ubuntu1
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.31-10.34-generic
> SourcePackage: gnome-power-manager
> Uname: Linux 2.6.31-10-generic i686
>

[Chris B (billington-chris)]

Not a lot of success with this. There appear to be no debug symbols for
libgudev-1.0.0, or more to the point devicekit-power-daemon itself.

The daemon crashes after it tries to read the battery state with:

 - No updates on supply
/org/freedesktop/DeviceKit/Power/devices/battery_BAT0 for 30 seconds;
forcing update
TI:01:20:48 TH:0x8069bf8 FI:dkp-history.c
FN:dkp_history_schedule_save,587
 - deferring as others queued
TI:01:20:48 TH:0x8069bf8 FI:dkp-history.c
FN:dkp_history_schedule_save,587
 - deferring as others queued
TI:01:20:48 TH:0x8069bf8 FI:dkp-device.c
FN:dkp_device_perhaps_changed_cb,863
 - emitting changed on
/sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0
TI:01:20:48 TH:0x8069bf8 FI:dkp-device.c
FN:dkp_device_perhaps_changed_cb,865
 - emitting device-changed on
/sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0
TI:01:20:49 TH:0x8069bf8 FI:dkp-device-supply.c
FN:dkp_device_supply_refresh_battery,521
 - fixing up unknown 99.196429

Program exited with code 01.
(gdb) backtrace full
No stack.
(gdb) info registers
The program has no registers now.

On Fri, Oct 2, 2009 at 2:35 AM, Martin Pitt <email address hidden> wrote:

> Thanks for your report. I really doubt that it's due to the negative
> value, since (1) a SIGPIPE is very unlikey in this case, and (2) it
> crashes deep in D-BUS code which usually doesn't care about particular
> message values.
>
> Unfortunately the stack trace isn't very clear. You seem to be able to
> reproduce this reliably, any chance you could install some debugging
> symbols and use gdb again? https://wiki.ubuntu.com/DebuggingProgramCrash
> describes how to set up the debug symbol repository. You'll need these
> packages:
>
> sudo apt-get install devicekit-power-dbgsym libdbus-1-3-dbgsym
> libdbus-glib-1-2-dbgsym libdevkit-power-gobject1-dbgsym
> libgudev-1.0-0-dbgsym libglib2.0-0-dbgsym
>
> Thanks!
>
> Or even easier, the dk-power backend crash should be caught by Apport,
> and you should get offered to file a bug about it. This will
> automatically get post-processed to get a fully symbolic stack trace.
>
> ** Changed in: devicekit-power (Ubuntu)
> Status: New => Incomplete
>
> --
> Karmic Alpha 6: devicekit-power-daemon crash with SIGPIPE
> https://bugs.launchpad.net/bugs/434771
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “devicekit-power” package in Ubuntu: Incomplete
>
> Bug description:
> Binary package hint: devkit-power
>
> Karmic Alpha 6
> acpi, sys and proc filesystems all detect battery status, but devkit and
> g-p-m do not.
>
> It appears as if the issue stems from devkit-power-daemon, and
> gnome-power-manager is just reflecting that lack of status.
>
> $ devkit-power -d
> Device: /org/freedesktop/DeviceKit/Power/devices/battery_BAT0
> native-path: (null)
> power supply: no
> updated: Thu Jan 1 07:30:00 1970 (1253640103 seconds ago)
> has history: no
> has statistics: no
> unknown
>
> Device: /org/freedesktop/DeviceKit/Power/devices/line_power_AC0
> native-path:
> /sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_s...

[Martin Pitt (pitti)]

> There appear to be no debug symbols for libgudev-1.0.0, or more to the point devicekit-power-daemon itself.

Hmm, http://ddebs.ubuntu.com/pool/main/d/devicekit-power/ and
http://ddebs.ubuntu.com/pool/main/u/udev/ have them all. "apt-cache show devicekit-power-dbgsym" works, but not for libgudev-1.0-0-dbgsym, so you might need to download those ddebs manually. There's apparently something wrong with index file generation..

[Chris B (billington-chris)]

While one would expect the debug symbols to be part of the parent package-dbgsym, (udev-dbgsym for libgudev-debugsym, and devicekit-power-debugsym for devicekit-power-daemon, gdb still says there are no debug symbols installed.

I ran gdb with
 sudo gdb /usr/lib/devicekit-power/devkit-power-daemon 2>&1 |tee /home/chris/gdb-devicekit-power-daemon.txt

and get

Reading symbols from /usr/lib/devicekit-power/devkit-power-daemon...Reading symbols from /usr/lib/debug/usr/lib/devicekit-power/devkit-power-daemon...done.
(no debugging symbols found)...done.

It still terminates with

 - emitting changed on /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0
TI:23:37:31 TH:0x8069bf8 FI:dkp-device.c FN:dkp_device_perhaps_changed_cb,865
 - emitting device-changed on /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0
TI:23:37:31 TH:0x8069bf8 FI:dkp-device-supply.c FN:dkp_device_supply_get_design_voltage,318
 - using min design voltage
TI:23:37:31 TH:0x8069bf8 FI:dkp-device-supply.c FN:dkp_device_supply_refresh_battery,557
 - fixing up unknown 98.363095

Program exited with code 01.
(gdb)

And there is no backtrace.

This is with the Oct 6th upgrade of devicekit-power

Version: 011-1
Depends: libc6 (>= 2.4), libdbus-1-3 (>= 1.0.2), libdbus-glib-1-2 (>= 0.78), libdevkit-power-gobject1 (>= 010), libglib2.0-0 (>= 2.22.0), libgudev-1.0-0, libpolkit-gobject-1-0 (>= 0.94), libusb-0.1-4 (>= 2:0.1.12)
Recommends: pm-utils, policykit-1
Breaks: gnome-power-manager (<< 2.27.5), libdevkit-power-gobject1 (<< 011)
Conffiles:
 /etc/dbus-1/system.d/org.freedesktop.DeviceKit.Power.conf 0bb60f809dd90bf0de77447491435d08

Am I doing something wrong? What should I try next?

[Martin Pitt (pitti)]

Hm, if it doesn't actually crash now, then there won't be a backtrace, indeed. Another relatively easy way to debug this is strace:

sudo strace -vv -s 1024 -o /tmp/dkp.trace /usr/lib/devicekit-power/devkit-power-daemon -v

and then attach /tmp/dkp.trace here after it crashed. This will watch all subprocess as well, and should have the precise location of the SIGPIPE error.

[Chris B (billington-chris)]

Sorry for the delay. Here is the strace output.

[Martin Pitt (pitti)]

Thanks. That's inconclusive as well, I'm afraid. Currently I have no good idea how to debug this remotely :-(

[S Mendis (surakshan)]

Team,

I'm experiencing the exact same issue and hopefully the following information will contribute.
The laptop in question is a Dell 6400 circa 2005.

I have two batteries, only ONE has a problem (a non OEM one) and the other which is a Dell branded battery works fine. Both batteries report their status through HAL correctly. I can also get a status using the 'acpi' tool. Both batteries are therefore detected by Linux.

One common thing I've noted between my battery that doesn't work and this bug report is the OEM field as shown in the output:

ubuntu@ubuntu:~$ cat /proc/acpi/battery/BAT0/info
present: yes
design capacity: 7800 mAh
last full capacity: 7800 mAh
battery technology: rechargeable
design voltage: 11100 mV
design capacity warning: 780 mAh
design capacity low: 236 mAh
capacity granularity 1: 78 mAh
capacity granularity 2: 78 mAh
model number: DELL
serial number: 33
battery type: LION
OEM info: GW�
-------

I'm wondering if the ? mark in the OEM info field (GW?) is not being parsed properly causing devicekit-power-daemon to crash.

My original battery (that works in a reporting sense) has "OEM info: Sanyo" with no question mark. This battery works.

Again, I'd like to reiterate the battery that doesn't work reports its status fine through the acpi command and through HAL. i.e its not a dumb battery.

Do you think this is a parsing issue with the OEM info string?

[S.Mendis (s.mendis-redhat-bugs)]

Created attachment 368006
strace capture of devkit-power-daemon terminating prematurely

Description of problem:

Computer: Dell 6400 circa 2005.

When booting with a particular battery, the battery is not detected by Gnome Power Manager in Fedora 11. However this battery and all relevant status information is available through the following commands.

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

2. cat /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0/*

The *same* battery is detected fine in older distributions that also use gnome-power-manager but specifically ones that do not use devicekit-power

The same issue is reported in Ubuntu launchpad, which this report links to.

**IMPORTANT OBSERVATION**
The OEM field from the battery contains some unicode (?) characters. This is evident in the original bug report at Ubuntu as well as my output of the specific battery in question

e.g

$ cat /proc/acpi/battery/BAT0/info
.....
OEM info: GW�

I also have another battery which works fine with devicekit-power on the same laptop. This battery has

OEM info: Sanyo

i.e no unicode chars. All the other ACPI attributes are identical.

Therefore I have a feeling perhaps devkit-power or one of the subsystems it uses cannot deal with the special characters and so ultimately the dbus messages don't make it to gnome-power-manager.

Version-Release number of selected component (if applicable):

DeviceKit-power client version 010
DeviceKit-power daemon version 010
gnome-power-manager-2.26.4-3.fc11.i586

The same issue is observed in Ubuntu Karmic, they use DK-Power version 011

How reproducible: Always

Steps to Reproduce:

1. Power up with a particular battery, perhaps one that has unicode chars such as � in the ACPI attributes

Actual results:

1. strace devkit-daemon appears to prematurely terminate the moment the battery information is queried (e.g through gnome-power-statistics).

2. As a result gnome-power-manager cannot see the battery, however the acpi command and HAL see the battery fine.

The net impact is gnome cannot manage the laptop's power.

Additional info:

I am unable to obtain a backtrace (with debuginfo packages installed). This is consistent with the reports on Ubuntu's bug tracker as well.

However when running devkit-power-daemon through strace, the application terminates when I attempt to query the battery status (e.g using gnome-power-statistics)

[S.Mendis (s.mendis-redhat-bugs)]

Created attachment 368007
output of gnome-power-bugreport

output of gnome-power-bugreport, note that HAL detects everything fine but /org/freedesktop/DeviceKit/Power/devices/battery_BAT0 does not.

[Chris B (billington-chris)]

While I couldn't get a debug trace for this devicekit-power-daemon crash (or rather unexpected quit), I have now compiled a kernel with a custom DSDT, and the problem goes away.

These are the lines changed in the DSDT:

Original, as BIOS
Name (BBIF, Package (0x0D)
            {
                One,
                0x1130,
                0x1130,
                One,
                0x2B5C,
                Zero,
                Zero,
                Zero,
                0xFFFFFFFF,
                "T220",
                "",
                "LION",
                "Thread"
            })

Edited DSDT:
Name (BBIF, Package (0x0D)
            {
                One,
                0x1130,
                0x1130,
                One,
                0x2B5C,
                0x140,
                0xA0,
                0x10,
                0x10,
                "T220",
                "",
                "LION",
                "Thread"
            })

A few lines later in the _BIF Method, the line

Store (STR3, Index (BBIF, 0x0C))

was also removed, which was overriding the 'OEM INfo' field with the Unicode or binary contents of the variable STR3.

/proc/acpi/battery/BAT0/info before:

cat /proc/acpi/battery/BAT0/info
present: yes
design capacity: 3200 mAh
last full capacity: 3360 mAh
battery technology: rechargeable
design voltage: 7400 mV
design capacity warning: 0 mAh
design capacity low: 0 mAh
capacity granularity 1: 0 mAh
capacity granularity 2: -1 mAh
model number: 2S1P
serial number:
battery type: LION
OEM info: ��������������������������������

After:

cat /proc/acpi/battery/BAT0/info
present: yes
design capacity: 3200 mAh
last full capacity: 3360 mAh
battery technology: rechargeable
design voltage: 7400 mV
design capacity warning: 320 mAh
design capacity low: 160 mAh
capacity granularity 1: 16 mAh
capacity granularity 2: 16 mAh
model number: 2S1P
serial number:
battery type: LION
OEM info: Thread

It therefore appears that either the zero or negative values of the DSDT 'capacity granularity' constants or the apparently Binary contents of the 'OEM info' field (which end up in the /sys filesystem as POWER_SUPPLY_MANUFACTURER variable) are causing either dBus, udev or devkit-power-daemon to quit.

The process of loading a customised DSDT takes hours, since a new kernel has to be compiled (and maintained), which is definitely a retrograde step.

[Martin Pitt (pitti)]

Thanks! That should be possible to fake, for reproducing.

[Martin (martin-redhat-bugs)]

FYI, I just received a followup for this in Ubuntu that updating the DSDT fixed the crash.

/proc/acpi/battery/BAT0/info before:

cat /proc/acpi/battery/BAT0/info
present: yes
design capacity: 3200 mAh
last full capacity: 3360 mAh
battery technology: rechargeable
design voltage: 7400 mV
design capacity warning: 0 mAh
design capacity low: 0 mAh
capacity granularity 1: 0 mAh
capacity granularity 2: -1 mAh
model number: 2S1P
serial number:
battery type: LION
OEM info: ��������������������������������

After:

cat /proc/acpi/battery/BAT0/info
present: yes
design capacity: 3200 mAh
last full capacity: 3360 mAh
battery technology: rechargeable
design voltage: 7400 mV
design capacity warning: 320 mAh
design capacity low: 160 mAh
capacity granularity 1: 16 mAh
capacity granularity 2: 16 mAh
model number: 2S1P
serial number:
battery type: LION
OEM info: Thread

It therefore appears that either the zero or negative values of the DSDT 'capacity granularity' constants or the apparently binary contents of the 'OEM info' field (which end up in the /sys filesystem as POWER_SUPPLY_MANUFACTURER variable) are causing either dBus, udev or devkit-power-daemon to quit.

[S.Mendis (s.mendis-redhat-bugs)]

I can confirm removing the OEM info data (through a customised kernel that includes modified DSDT file) solves the problem (as a workaround at least).

After booting the modified kernel (which removes the data in OEM Info) I get the following output

cat /proc/acpi/battery/BAT0/info
present: yes
design capacity: 7800 mAh
last full capacity: 7800 mAh
battery technology: rechargeable
design voltage: 11100 mV
design capacity warning: 780 mAh
design capacity low: 236 mAh
capacity granularity 1: 78 mAh
capacity granularity 2: 78 mAh
model number: DELL
serial number: 33
battery type: LION
OEM info:

and devicekit-power doesn't quiet in an unexpected fashion.

Now we need to solve the inital 'quit' in one or more of these components dbus/udev/devkit-power-daemon.

Any ideas?

[S Mendis (surakshan)]

I've confirmed (in Fedora 11, see linked bug report) that removing the binary components of the OEM info field solves the reported problem.

Like Chris I loaded a customised DSDT table. However my change is only in relation to the OEM info field.

[Richard (richard-redhat-bugs)]

Can you load on the original DSDT and then try doing (as root):

debuginfo-install DeviceKit-power
killall devkit-power-daemon
gdb /usr/libexec/devkit-power-daemon

then in gdb type:

r --verbose

And then wait for devkit-power-daemon to explode. When it does, please type:

bt

and then post the entire output (including the verbose output) into this bug. Thanks.

[S.Mendis (s.mendis-redhat-bugs)]

Created attachment 369669
gdb /usr/libexec/devkit-power-daemon (verbose option)

As requested I've booted into a kernel without a custom DSDT (2.6.30.9-96.fc11.i686.PAE) and run devkit-power-daemon through gdb in verbose mode.

Note towards the bottom, "Detaching after fork from child process 2868", at this stage the program continues to run up.

However when he battery information is queried (I trigger this by simply runninig gnome-power-statistics) the program exits with 'code 01'

I then proceed to obtain a backtrace, (bt) which gdb responds with 'no stack'

[Richard (richard-redhat-bugs)]

Can you get the --verbose log of gnome-power-statistics when this happens please. Thanks.

[S.Mendis (s.mendis-redhat-bugs)]

Created attachment 369835
gnome-power-statistics --verbose

1. Since devkit-power-daemon crashes, I run it as root
# /usr/libexec/devkit-power-daemon --verbose

2. I then use run gnome-power-statistics, which queries the battery information, this causes devkit-power-daemon to quit (i.e the original report). The output of this is attached as requested

$ gnome-power-statistics --verbose

3. Note that gnome-power-statistics does not quit, it shows an "Unknown" device, which is the battery witih no useful information.

This is with the standard kernel, not the DSDT modifed one that removes the binary components of the OEM Info field.

[Richard (richard-redhat-bugs)]

I've fixed this in git master, thanks for your debugging traces:

commit 99ab6b00c06dc778d9f4b04e8a7048e0c938cb4f
Author: Richard Hughes <email address hidden>
Date: Tue Nov 17 13:30:25 2009 +0000

    Some vendors fill the NVRAM full of junk. Don't crash the daemon if the battery is broken. Fixes rh#533654

:100644 100644 5a1acd9... ac5e1e1... M src/linux/dkp-device-supply.c

Is there any chance you can try Fedora 12 and then i can give you a build to try? I'm not sure if this patch will apply cleanly to the DK-p in F11.

[Martin Pitt (pitti)]

Fixed upstream:

http://cgit.freedesktop.org/DeviceKit/DeviceKit-power/commit/?id=99ab6b00c06dc778d9f4b04e8a7048e0c938cb4f

[S.Mendis (s.mendis-redhat-bugs)]

Thanks - good stuff.

Downloading the F12 now, realistically it will be a few more days before I can install it. If you do get an opportunity to build against FC11 please let me know as well.

[S.Mendis (s.mendis-redhat-bugs)]

Richard, can I have a FC12 build to test out?

[Martin Pitt (pitti)]

Fixed in 013-1 in lucid.

[Chris B (billington-chris)]

Martin,
Is there any chance of a backport to Karmic?

Chris

On Mon, Dec 7, 2009 at 7:40 PM, Martin Pitt <email address hidden> wrote:

> Fixed in 013-1 in lucid.
>
> ** Changed in: devicekit-power (Ubuntu)
> Status: Fix Committed => Fix Released
>
>
>

[Martin Pitt (pitti)]

Chris B [2009-12-07 15:47 -0000]:
> Martin,
> Is there any chance of a backport to Karmic?

If someone wants to provide a package and drive the testing, I'm happy
to sponsor something.

[Chris B (billington-chris)]

The attached packages, built against Karmic with 2.6.31.16-generic kernel, fix the originally-reported issue for me on the machine with the internal battery.
No need for custom kernel with modified DSDT compiled-in any more.
Packages were built with prevu-nomangle.
Thanks very much for taking care of this bug!
Chris

[Marco (0m3g4)]

i have this problem and i'm using ubuntu 9.10 64 bit....is it possible to have 64 bit packages or when this fix will be released in karmic repo?

[Richard (richard-redhat-bugs)]

The current build in F12 should be working fine now. Thanks.

[Chris B (billington-chris)]

You can build the Lucid packages on your 64-bit system using the prevu backporting utility
There is a howto at https://wiki.kubuntu.org/Prevu

Probably, given the small number of people affected, there will be no official release until Lucid is out.

I can confirm that the Lucid packages work on my system, as do the Debian Sid versions. However, I don't know how to go about 'driving the testing' as Martin suggests.