Created attachment 368006 [details] 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)
Created attachment 368007 [details] 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.
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.
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?
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.
Created attachment 369669 [details] 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'
Can you get the --verbose log of gnome-power-statistics when this happens please. Thanks.
Created attachment 369835 [details] 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.
I've fixed this in git master, thanks for your debugging traces: commit 99ab6b00c06dc778d9f4b04e8a7048e0c938cb4f Author: Richard Hughes <richard> 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.
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.
Richard, can I have a FC12 build to test out?
The current build in F12 should be working fine now. Thanks.