[gpm] Intermittent problem with battery discharge detection

[Brian Hutsell <bhut_ooto yahoo com>]

Richard,

Thanks for your help with resolving a number of issues.  I need your help again.

With the latest versions of "gnome-power-manager" and "upower" from git master, I ran into an issue where my battery wasn't detected as discharging.  I had seen this before, but it wasn't until today when I actually caught with the debugger.  Plugging in the AC and removing it appears to correct the problem, and once it is fixed, I've not noticed the same problem until a subsequent reboot.

As far as I can tell, it's intermittent, so I can't really tell you how to reproduce it.  When the battery is detected late (e.g. not during coldboot), sometimes the battery is (mistakenly?) reported as being UP_DEVICE_STATE_FULLY_CHARGED, and even though we are really discharging the battery, the UP_DEVICE_STATE stays stuck at UP_DEVICE_STATE_FULLY_CHARGED.  I'm guessing that either a signal from somewhere was missed or not generated.

Here is some output from gdb:

(gdb) p *$21->priv
$30 = {object_path = 0x7de1a0 "/org/freedesktop/UPower/devices/battery_BAT1", 
  system_bus_connection = 0x7d7008, system_bus_proxy = 0x7edd20, 
  daemon = 0x7ea860, history = 0x7f0410, native = 0x803e30, 
  has_ever_refresh = 1, during_coldplug = 0, update_time = 1274428390, 
  vendor = 0x7f4100 "SANYO", model = 0x7da6f0 "AS07B31", serial = 0x7d41d0 "78", 
  native_path = 0x7f50f0 "/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT1", power_supply = 1, online = 0, is_present = 1, is_rechargeable = 1, 
  has_history = 1, has_statistics = 1, type = UP_DEVICE_KIND_BATTERY, 
  state = UP_DEVICE_STATE_FULLY_CHARGED, 
  technology = UP_DEVICE_TECHNOLOGY_LITHIUM_ION, capacity = 82.25, 
  energy = 40.170900000000003, energy_empty = 0, 
  energy_full = 40.170900000000003, energy_full_design = 48.840000000000003, 
  energy_rate = 18.1374, voltage = 11.994999999999999, time_to_empty = 0, 
  time_to_full = 0, percentage = 100, recall_notice = 0, recall_vendor = 0x0, 
  recall_url = 0x0}

(gdb) p *daemon->priv
$38 = {connection = 0x7d7008, proxy = 0x7e3c40, polkit = 0x7dc400, 
  backend = 0x7e2c40, power_devices = 0x7dc6d0, on_battery = 0, 
  on_low_battery = 0, lid_is_closed = 0, lid_is_present = 1, 
  kernel_can_suspend = 1, kernel_can_hibernate = 1, 
  hibernate_has_swap_space = 1, hibernate_has_encrypted_swap = 0, 
  during_coldplug = 0, sent_sleeping_signal = 0, battery_poll_id = 0, 
  battery_poll_count = 4294967295, about_to_sleep_timer = 0x7ea580, 
  about_to_sleep_id = 0, conf_sleep_timeout = 1000, 
  conf_allow_hibernate_encrypted_swap = 1}

(gdb) call (UpDeviceKind *)malloc(sizeof(UpDeviceKind))
$44 = (UpDeviceKind *) 0x7f44e0
(gdb) call (UpDeviceState *)malloc(sizeof(UpDeviceState))
$45 = (UpDeviceState *) 0x7db9e0
(gdb) call (gboolean *)malloc(sizeof(gboolean))
$46 = (gboolean *) 0x7e2b90
(gdb) call g_object_get($21, "type", $44, "state", $45, "is-present", $46, NULL)
No symbol "NULL" in current context.
(gdb) call g_object_get($21, "type", $44, "state", $45, "is-present", $46, 0)
$47 = 1
(gdb) p *$44
$48 = UP_DEVICE_KIND_BATTERY
(gdb) p *$45
$49 = UP_DEVICE_STATE_FULLY_CHARGED
(gdb) p *$46
$50 = 1

% more /sys/class/power_supply/BAT1/charge_now 
588000
% more /sys/class/power_supply/BAT1/charge_full
3619000

As you can see, the charge is at ~16%, but upowerd is still reporting the charge as FULLY_CHARGED.

Calling up_device_refresh_internal($21) appears to have fixed the problem, enabling detection that we're on_battery and computation of the proper levels.


I noticed the following code in upower/src/linux/up-device-supply.c:
        /* only disable the polling if the kernel tells us we're fully charged,
           not if we've guessed the state to be fully charged */
        supply->priv->enable_poll = (state != UP_DEVICE_STATE_FULLY_CHARGED);

Of course, the straightforward hack would be to set supply->priv->enable_poll = 1.  What bothers me is the part that says "the kernel tells us we're fully charged".  Is the kernel that unreliable?  I'm guessing there was a missed signal indicating we're discharging, but I don't know the code well enough to debug further.

Richard, do you have any instrumentation code you'd like me to add to debug this further, in case I can reproduce this again?

--Brian