Battery status behaves erratically

Thanks for reporting this bug. I've noticed something similar as well, if often warns me that the battery only has a few moments left, despite being at 99% charge. I even often see these warnings while it is plugged in. Quite strange.

I found it annoying at first and tried to disable the messages. The shutdowns due to it being critically low however make my system unusable.

@Francesco, which particular kernel were you using when you observed this issue? the output of "uname -a" is sufficient to get this info. And are you still seeing this issue now?

the issue is fully reproducable with the current archive kernel (and i think it started with the rebase to the new android kernel version). just let the battery drain below 50% and the notification noise will start at some point...

I installed the image Ubuntu Raring Ringtail (development branch) - armhf (20130124-15:18), and run a test to profile the battery draining on Nexus 7. I attach log and graph of the numbers. Sometimes, during the test, the capacity and charge_now values show 100 and a weird value. At no point the device suspended before 5% battery capacity.

I was running a "dd if=/dev/urandom of=/dev/null bs=1M" in the background, if that helps.

See Rplot of the draining, interesting values all around 100%.

The samples were taking twice a second.

note that there are two daemons running that arent power effective at all (they are shell script and poll from sysfs every second), they are interim solutions to be able to test the behavior of the features. for proper power measuring i would recommend to run:

sudo service luxd stop
sudo service acceld stop

to disable both of them (they will go away if the features are properly implemented in kernel and gnome-settings-daemon)

additionally there seems to be a bug with getty handling the serial gadget (bug 1105068) which will also cause additional battery draining. until this one is fixed, sudo service ttyGS0 should be used to shut it down if you want proper power measuring results.

note that disabling either of the above does not change any of the described behavior (but you will get more accurate battery data with them disabled).

I ran the Nexus 7 on idle all weekend and gathered battery data from the /sys/class/power_supply/battery/charge_now battery interface and from upower believes the battery state is in.

Attached is a spreadsheet containing the data + graphs. Note that at the hardware and kernel level we're getting fairly sane values. However, upower is reporting rather erratic values for "time to empty" values, which is probably the root cause. See the "graphs" tab in the spread sheet.

And I've also got some data for 4 fully loaded CPUs too running for over 5 hours. Again, raw capacity data from the /sys/class/power_supply/battery/charge_now interface compared to upower's battery estimate. As one can see, the hardware and kernel seem to be returning consistent and sane data, where as upower is reporting some poor estimations.

I've sanity checked the inputs to upowerd and they look sane, so I believe the issue is probably in the way upowerd calculates the time to empty values which then get passed up to higher desktop layers that decide to power down the machine. So this is not a kernel related bug IMHO.

Status changed to 'Confirmed' because the bug affects multiple users.

The issue here is a bug in the bq27541 fuel gauge driver. The get_property() function is not thread-safe, but reentry is possible in several different scenarios.

The attached patch fixes this issue by protecting get_property() via a mutex.

Below is the patch commit message, for clarity:

 * Currently, get_property() and its callees are not thread-safe, since
   they share some global state, which they access without serialization
   or guaranteed atomicity.

 * get_property() can be called in a reentrant fashion from either
   several concurrent sysfs accesses, or a sysfs access concurrently with
   an access from power_supply_core.c, which in turn are triggered from
   a work queue in the driver itself.

 * This fixes bogus readings affecting the capacity and the charge_now
   values - possibly others as well.

The attachment "0001-power-bq27541-driver-serialize-get_property.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

This bug was fixed in the package linux-nexus7 - 3.1.10-9.23

---------------
linux-nexus7 (3.1.10-9.23) raring; urgency=low

  [ Alex Hornung ]

  * SAUCE: power: bq27541 driver - serialize get_property
    - LP: #1093543
  * SAUCE: power: bq27541_battery - Provide energy measurement
    - LP: #1109183
 -- Andy Whitcroft <email address hidden> Tue, 29 Jan 2013 20:07:36 +0000

there is no change with this patch, turning back to confirmed

While gema's issue (which was dealing with raw sysfs read data) is gone with this patch, I suspect your issue might well be related to upower.

Did you try with the second patch as well? The "Provide energy measurement" ? A quick skim through the relevant upower code would indicate that it does try to use the "energy_now" node when present, which may change the behaviour you see.

Cheers,
Alex

The patch definitely fixed my issue, you could see the graph before, attach the graph after.

The other patch for energy_now measurements is the one shown in https://bugs.launchpad.net/ubuntu-nexus7/+bug/1093543.

 LP: #1109183, rather !

Actually I don't think the energy patch will change much. Fact is that, since we don't provide current_now nor power_now, upower will do,

 /* the hardware reporting failed -- try to calculate this */
 if (energy_rate < 0.01)
  energy_rate = up_device_supply_calculate_rate (supply, energy);

energy_rate will be 0 because of the absence of those two sysfs nodes.

I'd suspect any issue being in this software-based rate calculation. Something that would be worth trying out is providing a current_now node, which is something the fuel gauge chip provides. That would allow upower to use a different rate calculation mechanism and possibly avoid the issue altogether.

I'll post a quick patch to provide current_now in a bit.

Cheers,
Alex

Attached is a kernel patch to provide current_now. It may help with the upower issues, as it should result in upower using a different method to calculate the remaining time, etc.

Cheers,
Alex

awesome, i will test it during the day ...

testing a kernel with teh above patch doesnt seem to fix it either ... but i made an intresting observation:

right after first boot
ogra@nexus7:~$ upower -d |grep energy-full:
    energy-full: 73.66 Wh

the "energy-full" value actually should be a fixed value coming from the battery describing the upper charge level...

after a reboot:

ogra@nexus7:~$ upower -d |grep energy-full:
    energy-full: 69.42 Wh

and indeed the battery applet (with "show time" set in the options) immediately show 100% charge at boot (even though thats nonsense indeed)

so i think our base value used to compute the time in upower is reported wrongly (or read wrongly by upower)

For me the Nexus 7 says that the battery is low with 100%. Also the Pandaboard behaves strangely, sometimes it shows that it has a battery, sometimes that it has no battery but I never get no battery symbol in the indicator area at all (as it should be for a device without battery).

This bug was fixed in the package linux-nexus7 - 3.1.10-9.24

---------------
linux-nexus7 (3.1.10-9.24) raring; urgency=low

  [ Alex Hornung ]

  * SAUCE: power: bq27541_battery - Provide current_now
    - LP: #1093543

  [ Andy Whitcroft ]

  * [Config] switch from USB_G_SERIAL to USB_CDC_COMPOSITE
 -- Andy Whitcroft <email address hidden> Wed, 30 Jan 2013 12:14:28 +0000

Well, here go 3 more patches.... 1 for upower, 2 for the kernel.

The upower one just fixes a logic bug that will allow the design capacity to be read via charge, even though the current energy is read directly as energy.

The kernel patches are:
1) Fix a bug in a previous patch - even though the datasheet says that energy_now is in units of 10 mWh, it turns out it isn't - it is in units of mWh.
2) Add charge_full and charge_full_design nodes.

With these patches, upower seems to report the right percentage, time to empty, etc.

Would appreciate some testing from someone suffering from the problem. Remember to apply all the patches (the upower one, these two kernel ones, and depending on which kernel you are running, also the patches that add the current_now and energy_now fields - although those are committed already).

Cheers,
Alex

PS: launchpad only supports one attachment per comment, it seems, so the rest are in separate comments.

Fixes units of energy_now (10mWh -> mWh)

Adds charge_full and charge_full_design nodes/measurements.

PS: note that the upower patch is against the upstream version, so it may or may not apply cleanly to the version ubuntu has. Nonetheless, it should be straight forward to apply the patch manually - it's just 1 line.

The patch for charge_full and charge_full_design

(NOTE that I updated the patch for charge_full and charge_full_design - yesterday I forgot to commit one last diff before generating the patch).

All of these patches have now been sent upstream as well. The android one for energy_now has been updated with all the other extra measurements.

https://bugs.freedesktop.org/show_bug.cgi?id=60104
https://android-review.googlesource.com/#/c/50742/
https://android-review.googlesource.com/#/c/50732/

I committed the patch upstream and wrote a corresponding test case.

Martin, for whatever it's worth, the following upower bug I filed might also be related - since an idle nexus 7 has a longer battery life than 20 hours, one would hope.

https://bugs.freedesktop.org/show_bug.cgi?id=60110

Cheers,
Alex

Alex, indeed. I followed up to the upstream bug and will discuss that with Richard once he comes online.

This bug was fixed in the package upower - 0.9.19-1ubuntu4

---------------
upower (0.9.19-1ubuntu4) raring; urgency=low

  * Add battery_mixed_charge_energy_test.patch: Fix batteries which report the
    current energy (µWh), but only the full charge (µAh). Thanks Alex Hornung
    for the patch! (LP: #1093543)
  * Add battery_mixed_charge_energy_test.patch: Test case for the previous
    patch.
 -- Martin Pitt <email address hidden> Thu, 31 Jan 2013 10:28:33 +0100

Reopening kernel task, as two patches haven't been applied yet.

testing with all patches applied this seems to fix it ...

a test kernel is here http://people.canonical.com/~ogra/tegra/nexus7/linux-image-3.1.10-9-nexus7_3.1.10-9.24_armhf.deb

I'm still having the issue on kernel 3.1.10-9.27, no matter what I attempt or try, ubuntu always thinks the nexus 7 is about dead.

I was curious if there was anymore on this as there hasn't been a post in a month and searching for this issue returned nothing other than this site.

I'm not sure what all i can do to help, but if you need more info I'm all ears.