Battery status behaves erratically

Bug #1093543 reported by Francesco Mateotti on 2012-12-25
32
This bug affects 7 people
Affects Status Importance Assigned to Milestone
ubuntu-nexus7
Medium
Unassigned
linux-nexus7 (Ubuntu)
High
Andy Whitcroft
upower (Ubuntu)
Undecided
Martin Pitt

Bug Description

I've recently updated my nexus and I've noticed that the battery system behaves very erratically. It will say that the battery is at 43%, 1 hour left, then say it is low with 43% and 1 minute left. At some points it says the battery is critical and shuts down the screen, only to re-awake soon after saying that the battery is simply low. The percentage seems to remain constant, however the time left changes.

Robert Bruce Park (robru) wrote :

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.

Changed in ubuntu-nexus7:
importance: Undecided → Medium
status: New → Confirmed
Francesco Mateotti (fmateotti) wrote :

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.

tags: added: nexus7-kernel
tags: added: mobile
Changed in ubuntu-nexus7:
assignee: nobody → Colin King (colin-king)
Colin Ian King (colin-king) wrote :

@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?

Oliver Grawert (ogra) wrote :

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...

Gema Gomez (gema) wrote :

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.

Gema Gomez (gema) wrote :

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

Gema Gomez (gema) wrote :

The samples were taking twice a second.

Oliver Grawert (ogra) wrote :

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).

Colin Ian King (colin-king) wrote :

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.

Colin Ian King (colin-king) wrote :

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.

Colin Ian King (colin-king) wrote :

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.

Changed in ubuntu-nexus7:
assignee: Colin King (colin-king) → nobody
Alex Chiang (achiang) on 2013-01-28
tags: added: sensors
Launchpad Janitor (janitor) wrote :

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

Changed in upower (Ubuntu):
status: New → Confirmed
Gema Gomez (gema) on 2013-01-29
Changed in upower (Ubuntu):
status: Confirmed → New
Changed in upower (Ubuntu):
status: New → Confirmed
bwalex (ahornung) wrote :

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.]

tags: added: patch
Andy Whitcroft (apw) on 2013-01-29
Changed in ubuntu-nexus7:
assignee: nobody → Andy Whitcroft (apw)
status: Confirmed → Fix Committed
status: Fix Committed → New
assignee: Andy Whitcroft (apw) → nobody
Changed in linux-nexus7 (Ubuntu):
status: New → Fix Committed
importance: Undecided → High
assignee: nobody → Andy Whitcroft (apw)
Launchpad Janitor (janitor) wrote :

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

Changed in linux-nexus7 (Ubuntu):
status: Fix Committed → Fix Released
Oliver Grawert (ogra) wrote :

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

Changed in linux-nexus7 (Ubuntu):
status: Fix Released → Confirmed
bwalex (ahornung) wrote :

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

Gema Gomez (gema) wrote :

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.

Gema Gomez (gema) wrote :

 LP: #1109183, rather !

bwalex (ahornung) wrote :

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

bwalex (ahornung) wrote :

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

Oliver Grawert (ogra) wrote :

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

Oliver Grawert (ogra) wrote :

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).

Launchpad Janitor (janitor) wrote :

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

Changed in linux-nexus7 (Ubuntu):
status: Confirmed → Fix Released
bwalex (ahornung) wrote :

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.

bwalex (ahornung) wrote :

Fixes units of energy_now (10mWh -> mWh)

bwalex (ahornung) wrote :

Adds charge_full and charge_full_design nodes/measurements.

bwalex (ahornung) wrote :

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.

bwalex (ahornung) wrote :

The patch for charge_full and charge_full_design

bwalex (ahornung) wrote :

(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/

Martin Pitt (pitti) wrote :

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

Changed in upower (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
status: Confirmed → In Progress
bwalex (ahornung) wrote :

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

Martin Pitt (pitti) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in upower (Ubuntu):
status: In Progress → Fix Released
Martin Pitt (pitti) wrote :

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

Changed in linux-nexus7 (Ubuntu):
status: Fix Released → Triaged
Oliver Grawert (ogra) wrote :

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

Changed in ubuntu-nexus7:
status: New → Triaged

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.