g-p-m doesn't save charge and discharge profiles

[Jorge Nerín]

Binary package hint: gnome-power-manager

There is a question in https://answers.launchpad.net/ubuntu/+source/gnome-power-manager/+question/51483 about g-p-m losing all the info about charge/discharge profile after a restart or suspend.

All that seems to be common is:
Ubuntu 8.10 (8.04 worked OK)
g-p-m 2.24.0
Laptop Asus Eee PC 901

ACPI and everything else seems to be OK, g-p-m works ok in a session, but the moment the system is restarted, suspended/resumed or AC is plugged/unplugged, g-p-m will forget all the collected data points. The files in ~/.gnome2/gnome-power-manager doesn't seem to be correct.

I have taken a peek inside the profile-901-55048-charging.csv and profile-901-55048-discharging.csv that are the ones with the last modified time, the charging one seems ok but empty, now I'm running on battery so I have no history (flat line):
profile-901-55048-charging.csv
0, 0, 0
1, 0, 0
2, 0, 0
3, 0, 0
4, 0, 0
5, 0, 0
6, 0, 0
7, 0, 0
[...]
96, 0, 0
97, 0, 0
98, 0, 0
99, 0, 0

The discharging one is a bit weird profile-901-55048-discharging.csv
0, 0, 0
0, 0, 0
0, 0, 0
0, 0, 0
0, 0, 0
0, 0, 0
0, 226, 0
0, 226, 0
0, 226, 0
0, 226, 0
0, 226, 0
0, 226, 0
[...]
0, 226, 0
0, 226, 0
0, 209, 17
0, 240, 17
0, 239, 17
0, 209, 17
0, 239, 17
0, 210, 16
0, 239, 17
0, 210, 17
0, 209, 16
0, 239, 17
0, 240, 18
0, 209, 16
[...]
0, 240, 14
0, 210, 11
0, 240, 15
0, 239, 16
0, 240, 18
0, 270, 18
0, 0, 0

both files have 100 lines, but something seems wrong, now I have switched to charging the files g-p-m is writing have changed :
profile-901-48797-charging.csv
0, 0, 0
0, 0, 0
0, 0, 0
0, 0, 0
0, 0, 0
0, 0, 0
0, 106, 0
0, 106, 0
0, 106, 0
0, 106, 0
0, 106, 0
0, 106, 0
[...]
0, 120, 14
0, 89, 14
0, 89, 13
0, 90, 8
0, 119, 10
0, 89, 6
0, 90, 6
0, 120, 10
0, 89, 9
0, 119, 7
0, 120, 17
0, 150, 17
0, 149, 18
0, 149, 17
0, 210, 17
0, 210, 18
0, 0, 0
0, 0, 0
0, 0, 0
0, 0, 0
0, 0, 0

profile-901-48797-discharging.csv
0, 0, 0
1, 0, 0
2, 0, 0
3, 0, 0
4, 0, 0
5, 0, 0
6, 0, 0
7, 0, 0
8, 0, 0
9, 0, 0
10, 0, 0
11, 0, 0
[...]
94, 0, 0
95, 0, 0
96, 0, 0
97, 0, 0
98, 0, 0
99, 0, 0

So now they seem reversed. I think that the csv is wrong in profile-901-55048-discharging.csv and profile-901-48797-charging.csv and empty in the other ones.

I expected g-p-m to save save/discharge profiles as it did in 8.04 and what happened is that whenever a change in the energy status of the laptop happens g-p-m loses the collected data points.

The output of gnome-power-bugreport.sh:
Distro version: DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.10
DISTRIB_CODENAME=intrepid
DISTRIB_DESCRIPTION="Ubuntu 8.10"
Kernel version: 2.6.27-8-eeepc
g-p-m version: 2.24.0
HAL version: 0.5.11
System manufacturer: missing
System version: missing
System product: missing
AC adapter present: yes
Battery present: yes
Laptop panel present: yes
CPU scaling present: yes
Battery Information:
  battery.charge_level.current = 50635 (0xc5cb) (int)
  battery.charge_level.design = 54140 (0xd37c) (int)
  battery.charge_level.last_full = 52634 (0xcd9a) (int)
  battery.charge_level.percentage = 96 (0x60) (int)
  battery.charge_level.rate = 8302 (0x206e) (int)
  battery.is_rechargeable = true (bool)
  battery.model = '901' (string)
  battery.present = true (bool)
  battery.rechargeable.is_charging = false (bool)
  battery.rechargeable.is_discharging = true (bool)
  battery.remaining_time = 21956 (0x55c4) (int)
  battery.reporting.current = 6154 (0x180a) (int)
  battery.reporting.design = 6580 (0x19b4) (int)
  battery.reporting.last_full = 6397 (0x18fd) (int)
  battery.reporting.rate = 1009 (0x3f1) (int)
  battery.reporting.technology = 'Li-ion' (string)
  battery.reporting.unit = 'mAh' (string)
  battery.serial = '' (string)
  battery.technology = 'lithium-ion' (string)
  battery.type = 'primary' (string)
  battery.vendor = 'ASUS' (string)
  battery.voltage.current = 8228 (0x2024) (int)
  battery.voltage.design = 8400 (0x20d0) (int)
  battery.voltage.unit = 'mV' (string)
GNOME Power Manager Process Information:
coma 8793 0.0 1.5 35584 16296 ? Ss Nov21 0:41 gnome-power-manager
coma 21116 0.3 1.3 30000 13924 ? S 18:11 0:34 gnome-power-statistics
coma 28598 1.2 1.6 31512 17404 ? S 20:16 0:16 file-roller file:///tmp/gnome-power-manager.tar.gz
HAL Process Information:
111 5338 0.0 0.2 6320 2636 ? Ss Nov21 0:30 /usr/sbin/hald
root 5342 0.0 0.1 3364 1112 ? S Nov21 0:00 \_ hald-runner
root 5424 0.0 0.1 3436 1028 ? S Nov21 0:00 \_ hald-addon-input: Listening on /dev/input/event3 /dev/input/event8 /dev/input/event6 /dev/input/event4 /dev/input/event5 /dev/input/event1 /dev/input/event7
root 5431 0.0 0.0 3448 988 ? S Nov21 0:00 \_ /usr/lib/hal/hald-addon-cpufreq
111 5432 0.0 0.0 2296 920 ? S Nov21 0:00 \_ hald-addon-acpi: listening on acpid socket /var/run/acpid.socket

Some events while running on battery:
$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
20:40:12.396: computer_power_supply_battery_BAT0 property battery.remaining_time = 20773 (0x5125)
20:40:12.409: computer_power_supply_battery_BAT0 property battery.charge_level.rate = 8690 (0x21f2)
20:40:12.419: computer_power_supply_battery_BAT0 property battery.charge_level.current = 50146 (0xc3e2)
20:40:12.434: computer_power_supply_battery_BAT0 property battery.reporting.current = 6111 (0x17df)
20:40:12.441: computer_power_supply_battery_BAT0 property battery.reporting.rate = 1059 (0x423)
20:40:42.396: computer_power_supply_battery_BAT0 property battery.remaining_time = 21998 (0x55ee)
20:40:42.411: computer_power_supply_battery_BAT0 property battery.charge_level.rate = 8191 (0x1fff)
20:40:42.425: computer_power_supply_battery_BAT0 property battery.charge_level.design = 53956 (0xd2c4)
20:40:42.439: computer_power_supply_battery_BAT0 property battery.charge_level.last_full = 52455 (0xcce7)
20:40:42.445: computer_power_supply_battery_BAT0 property battery.charge_level.current = 50052 (0xc384)
20:40:42.452: computer_power_supply_battery_BAT0 property battery.reporting.current = 6104 (0x17d8)
20:40:42.459: computer_power_supply_battery_BAT0 property battery.reporting.rate = 999 (0x3e7)
20:40:42.466: computer_power_supply_battery_BAT0 property battery.voltage.current = 8200 (0x2008)

Some DBUS events (plugging AC cord):
$ dbus-monitor --session "type='signal',interface='org.freedesktop.PowerManagement'"
signal sender=org.freedesktop.DBus -> dest=:1.223 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.223"
signal sender=:1.55 -> dest=(null destination) path=/org/freedesktop/PowerManagement; interface=org.freedesktop.PowerManagement; member=OnBatteryChanged
   boolean false
signal sender=:1.55 -> dest=(null destination) path=/org/freedesktop/PowerManagement; interface=org.freedesktop.PowerManagement; member=PowerSaveStatusChanged
   boolean false

[Matti Laakso (matti-laakso)]

It seems to me that since the battery does not provide a serial number, gpm uses 'battery.charge_level.design', i.e., its capacity as the battery identifier. However, at least on my Eee 901 it seems to change along with the battery charge level! Therefore gpm thinks that the battery has been changed.

It seems that the 'battery.reporting.design' is the correct identifier for the battery capacity on Eee 901.

[Jorge Nerín (jnerin)]

I'm not sure the name of the file is the culprint. I asked two friends winth different laptops to send me the contents of ~/.gnome2/gnome-power-manager, both of them are free of this bug, one has lots of files in this directory while the other one has four. There seems to be some problems in the naming of the files (some repated elements in some names):

User A:

profile-XM8001P02-XM8001P02-discharging.csv
profile-XM8001P02-discharging.csv
profile-XM8001P02-charging.csv
profile-XM8001P02-XM8001P02-charging.csv

User B:

profile-47836-charging.csv
profile-47836-discharging.csv
profile-49483-charging.csv
profile-49483-discharging.csv
profile-49924-charging.csv
profile-49924-discharging.csv
profile-50097-charging.csv
profile-50097-discharging.csv
profile-50179-charging.csv
profile-50179-discharging.csv
profile-50284-charging.csv
profile-50284-discharging.csv
profile-50366-charging.csv
profile-50366-discharging.csv
profile-50654-charging.csv
profile-50654-discharging.csv
profile-51004-charging.csv
profile-51004-discharging.csv
profile-51148-charging.csv
profile-51148-discharging.csv
profile-51177-charging.csv
profile-51177-discharging.csv
profile-51264-charging.csv
profile-51264-discharging.csv
profile-51273-charging.csv
profile-51273-discharging.csv
profile-51340-charging.csv
profile-51340-discharging.csv
profile-51364-charging.csv
profile-51364-discharging.csv
profile-51465-charging.csv
profile-51465-discharging.csv
profile-51964-charging.csv
profile-51964-discharging.csv
profile-52123-charging.csv
profile-52123-discharging.csv
profile-52128-charging.csv
profile-52128-discharging.csv
profile-52204-charging.csv
profile-52204-discharging.csv
profile-52228-charging.csv
profile-52228-discharging.csv
profile-52238-charging.csv
profile-52238-discharging.csv
profile-52353-charging.csv
profile-52353-discharging.csv
profile-52492-charging.csv
profile-52492-discharging.csv
profile-52588-charging.csv
profile-52588-discharging.csv
profile-52636-charging.csv
profile-52636-discharging.csv
profile-52646-charging.csv
profile-52646-discharging.csv
profile-52723-charging.csv
profile-52723-discharging.csv
profile-52732-charging.csv
profile-52732-discharging.csv
profile-52776-charging.csv
profile-52776-discharging.csv
profile-52780-charging.csv
profile-52780-discharging.csv
profile-52939-charging.csv
profile-52939-discharging.csv
profile-53011-charging.csv
profile-53011-discharging.csv
profile-53097-charging.csv
profile-53097-discharging.csv
profile-53136-53280-charging.csv
profile-53136-53280-discharging.csv
profile-53145-charging.csv
profile-53145-discharging.csv
profile-53150-charging.csv
profile-53150-discharging.csv
profile-53179-charging.csv
profile-53179-discharging.csv
profile-53184-charging.csv
profile-53184-discharging.csv
profile-53198-charging.csv
profile-53198-discharging.csv
profile-53203-charging.csv
profile-53203-discharging.csv
profile-53208-charging.csv
profile-53208-discharging.csv
profile-53217-charging.csv
profile-53217-discharging.csv
profile-53222-charging.csv
profile-53222-discharging.csv
profile-53260-charging.csv
profile-53260-discharging.csv
profile-53280-53280-53280-charging.csv
profile-53280-53280-53280-discharging.csv
profile-53280-5...

[Jorge Nerín (jnerin)]

After some more digging I have to agree 100% with Matti Laakso. If I launch g-p-m --debug --no-daemon I see this:

TI:10:58:48 TH:0x9c30640 FI:gpm-cell-unit.c FN:gpm_cell_unit_print,78
 - charge design 54521
[...]
TI:10:58:48 TH:0x9c30640 FI:gpm-profile.c FN:gpm_profile_set_config_id,783
 - config_id = 901-54521
TI:10:58:48 TH:0x9c30640 FI:gpm-profile.c FN:gpm_profile_load_data,734
 - loading battery data from '/home/coma/.gnome2/gnome-power-manager/profile-901-54521-discharging.csv'
*** WARNING ***
TI:10:58:48 TH:0x9c30640 FI:gpm-array.c FN:gpm_array_load_from_file,265
 - cannot open file /home/coma/.gnome2/gnome-power-manager/profile-901-54521-discharging.csv
TI:10:58:48 TH:0x9c30640 FI:gpm-profile.c FN:gpm_profile_load_data,745
 - no data found, generating initial (poor) data
TI:10:58:48 TH:0x9c30640 FI:gpm-profile.c FN:gpm_profile_load_data,734
 - loading battery data from '/home/coma/.gnome2/gnome-power-manager/profile-901-54521-charging.csv'
*** WARNING ***
TI:10:58:48 TH:0x9c30640 FI:gpm-array.c FN:gpm_array_load_from_file,265
 - cannot open file /home/coma/.gnome2/gnome-power-manager/profile-901-54521-charging.csv
TI:10:58:48 TH:0x9c30640 FI:gpm-profile.c FN:gpm_profile_load_data,745
 - no data found, generating initial (poor) data

So the assumption of Matti Laakso is correct. And I think this model is not the only one that reports a different battery.charge_level.design in each cycle, so far battery.reporting.design (6580 now) seems to be more correct. I don't known what should be the correct way to detect a different battery, but I think that most users only have one battery, so perhaps the default should be to assume that it is always the same battery and provide some way to disable the behavior for people with multiple batteries.

$ lshal |grep battery
udi = '/org/freedesktop/Hal/devices/computer_power_supply_battery_BAT0'
  battery.charge_level.current = 35000 (0x88b8) (int)
  battery.charge_level.design = 50218 (0xc42a) (int)
  battery.charge_level.last_full = 48791 (0xbe97) (int)
  battery.charge_level.percentage = 71 (0x47) (int)
  battery.charge_level.rate = 8005 (0x1f45) (int)
  battery.is_rechargeable = true (bool)
  battery.model = '901' (string)
  battery.present = true (bool)
  battery.rechargeable.is_charging = false (bool)
  battery.rechargeable.is_discharging = true (bool)
  battery.remaining_time = 15740 (0x3d7c) (int)
  battery.reporting.current = 4586 (0x11ea) (int)
  battery.reporting.design = 6580 (0x19b4) (int)
  battery.reporting.last_full = 6393 (0x18f9) (int)
  battery.reporting.rate = 1049 (0x419) (int)
  battery.reporting.technology = 'Li-ion' (string)
  battery.reporting.unit = 'mAh' (string)
  battery.serial = '' (string)
  battery.technology = 'lithium-ion' (string)
  battery.type = 'primary' (string)
  battery.vendor = 'ASUS' (string)
  battery.voltage.current = 7632 (0x1dd0) (int)
  battery.voltage.design = 8400 (0x20d0) (int)
  battery.voltage.unit = 'mV' (string)
  info.capabilities = {'battery'} (string list)
  info.category = 'battery' (string)
  info.udi = '/org...

[Scott Minster (sminster)]

I have a similar problem on my HP Pavilion dv6700 laptop. 'battery.reporting.design' is constant, but 'battery.charge_level.design' changes. Is there any way to configure g-p-m to use the former value, or is this something set in the code?

[Scott Minster (sminster)]

It looks like this value is used in the code and not configurable. I downloaded the source and found were 'battery.charge_level.design' was used in src/gpm-cell.c. Instead of changing that, however, I just commented out its usage in gpm_cell_get_id() to not use that value in constructing the ID. See the attached patch for information.

I think this might have been how it used to be, because I had older ~/.gnome2/gnome-power-manager/profile-Primary-{dis,}charging.csv files that didn't have the "design" ID.

Obviously, this patch is just a quick hack. I don't know enough about g-p-m to know what is the correct solution. Whether that is just removing the charge_level code I commented out, or making it an option, or something entirely different.

Does anyone know if there is an upstream gnome bug for this issue?

[Jorge Nerín (jnerin)]

I haven't found an upstream bug about this, and I'm not sure if we should be the ones submitting it or the ubuntu package maintainer.

I have been searching for a way to write a serial number to the battery so it will be reported by acpi, but so far I haven't found a way to do this nor I have found if it's even possible. After much thinking about the correct way to identify uniquely between various batteries I'm convinced that the correct way would be to be able to write a serial number if the battery hasn't one. Other correct way would be that the user manually identifies the battery each time the system has doubts, a major PITA.

I'm still searching about the way to modify the serial number field in acpi.

[David Iwanowitsch (dav.id)]

I confirm this bug, since it affects me too.
On EEEPc 901/Intrepid.

[Pedro Villavicencio (pedro)]

this was fixed upstream.

[David Iwanowitsch (dav.id)]

I have added a Patch, which works fine for me, it is based on the upstream patch from Stephen Gildea and Joe.

[ericwait (eric-waitphoto)]

I apologizes for the newbie question but, how do you apply the patch given by David?

I have tried:
# patch -p0 < gpm.patch
but it seems like I am missing much more. Do I need the source files first and then rebuild / install it after applying the patch?

Thanks.

[lokað (lokad)]

I am using current Ubuntu Jaunty (as of Mar 24) with gnome-power-manager 2.24.2-2ubuntu7 and still experience this bug.

eee:~$ LC_ALL=C ls -l .gnome2/gnome-power-manager/
total 192
-rw-r--r-- 1 rene rene 890 Mar 19 23:00 profile-1000H-47599-charging.csv
-rw-r--r-- 1 rene rene 890 Mar 19 23:00 profile-1000H-47599-discharging.csv
-rw-r--r-- 1 rene rene 890 Mar 21 03:59 profile-1000H-47678-charging.csv
-rw-r--r-- 1 rene rene 890 Mar 21 03:59 profile-1000H-47678-discharging.csv
[...]

The battery runtime is unpredictable.

The bug is fixed upstream but will this fix make it into Jaunty?

[akhenaton (aky-home)]

my new eeepc 1000h is also affected by this bug; using jaunty beta, all packages are updated
i hope the fix will make it to 9.04

[Pobice (robert-pobice)]

Unfortunately this bug still effects me even with the patch. On my HP 6730s battery.reporting.design also changes.

Reported upstream - http://bugzilla.gnome.org/show_bug.cgi?id=579357

Will have to comment the relevant code for now....

[Ondrej Certik (ondrej-certik)]

It also affects me, Jaunty, laptop is dell XPS M1330. E.g. the profiles get reset after each reboot, but my .gnome2/gnome-power-manager/ contain all the data:

$ ls .gnome2/gnome-power-manager/
profile-DELL_NT3408-32175-21357-charging.csv
profile-DELL_NT3408-32175-21357-discharging.csv
profile-DELL_NT3408-36821-21357-charging.csv
profile-DELL_NT3408-36821-21357-discharging.csv
profile-DELL_NT3408-37645-21357-charging.csv
profile-DELL_NT3408-37645-21357-discharging.csv
profile-DELL_NT3408-38480-21357-charging.csv
profile-DELL_NT3408-38480-21357-discharging.csv
profile-DELL_WR0538-86580-100-charging.csv
profile-DELL_WR0538-86580-100-discharging.csv

Did someone package the new upstream version, where this is fixed?

[Pobice (robert-pobice)]

I've added the patch into ubuntus version and uploaded it to my ppa:
https://launchpad.net/~robert-pobice/+archive/ppa

If that doesn't work there akways the botched version I use on my HP6730:
https://launchpad.net/~robert-pobice/+archive/botch-fixes

[karit (nzkarit)]

Thanks Pobice it is currently working for me on my eeepc901

[ericwait (eric-waitphoto)]

I thank Pobice as well. It is working on my HP dv6700 laptop! My battery history hasn't worked since 8.04, now running 9.04.

[Ondrej Certik (ondrej-certik)]

Thanks Pobice, seems to be working for me too. When I changed the battery, it got confused though, but otherwise it works fine.

[Kim Sullivan (alicebot)]

Pobice, thanks for the ppa! I'll try to use the botched fix, because my HP nx7400 has the same problem as your HP6730. The only problem I had was switching to the botched version, because I already had the "normal" version installed.

[Chris Coulson (chrisccoulson)]

Closing as fixed. The fixed version has been in Ubuntu for a few weeks now.