If it's not too late, can you file feedback for the full log set?

Sorry, I've rebooted a few times since then. :-(

If the logs you want are somewhere under /var/log, I'm happy to attach them.

There may still be useful logs around. Can you file feedback right now and include "shawnn" in the feedback text?

Sure thing; it's at http://feedback/#/Report/52480983053. I'll file a report immediately if I see it again.

I just saw this again at boot and send a feedback report after logging in: http://feedback/#/Report/52867022246

powerd got a few good readings before the bad one:

[0207/121222:INFO:daemon.cc(777)] On USB (USB_C, 0.000A at 4.8V, max 3.0A at 5.0V) with battery at 89% (displayed as 92%), 4.731/5.323Ah at 0.748A, 0s until full (calculating)
...
[0207/121222:INFO:daemon.cc(777)] On USB (USB_C, 0.000A at 4.8V, max 3.0A at 5.0V) with battery at 89% (displayed as 92%), 4.731/5.323Ah at 0.748A, 0s until full (calculating)
...
[0207/121226:INFO:daemon.cc(777)] On USB (USB_C, 0.000A at 4.8V, max 3.0A at 5.0V) with battery at 8% (displayed as 5%), 4.731/62.246Ah at 0.307A, 0s until full (calculating)
...
[0207/121227:INFO:daemon.cc(777)] On USB (USB_C, 0.000A at 4.8V, max 3.0A at 5.0V) with battery at 89% (displayed as 92%), 4.731/5.323Ah at 0.378A, 1h10s until full

Another probable case (search for "53.280"):

https://feedback.corp.google.com/#/Report/55485297462

This issue is repro'able by spamming `cat ...charge_full` during suspend_stress_test. Prior to https://chromium-review.googlesource.com/492546, we were seeing wild values due to 16 bit truncation, now we consistently see either the expected value, or the expected value converted to energy units (* nominal voltage / 10).

The issue is likely caused by kernel preemption during sbs_get_battery_capacity(). Certain battery properties are influenced by the CAPACITY_MODE bit, so we ensure we're in the desired mode (ENERGY vs CHARGE) before reading the property. If multiple tasks are reading properties at the same time, we have no guarantee that CAPACITY_MODE is still in the expected state during the actual read. This should be fixable by locking a mutex through much of sbs_get_battery_capacity(). I'll put up a CL.

Fix posted here, and also sent upstream: https://chromium-review.googlesource.com/#/c/531760/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/28878159180029badf429ae844b6a78221707ee8

commit 28878159180029badf429ae844b6a78221707ee8
Author: Shawn Nematbakhsh <shawnn@chromium.org>
Date: Wed Jun 14 23:25:22 2017

CHROMIUM: power: sbs-battery: Prevent CAPACITY_MODE races

A subset of smart battery commands return charge or energy depending on
the CAPACITY_MODE bit setting of BatteryMode(). In order to
unambiguously read a charge or energy value, it is necessary to ensure
that CAPACITY_MODE is set as desired, and not changed for the duration
of the attribute read.

BUG= chromium:686942 
TEST=On kevin, spam reads to charge_full battery sysfs attribute while
performing suspend_stress_test, verify that the same value is always
returned.

Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ic39e8d7f982d7045a2da6bf6fe835c2c3434815c
Reviewed-on: https://chromium-review.googlesource.com/531760
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>

[modify] https://crrev.com/28878159180029badf429ae844b6a78221707ee8/drivers/power/sbs-battery.c

This was fixed in M-61.  I don't think we need a merge to M-60, but we can if you think this is common.  Note that the existing EC firmware on kevin reports many things wrong anyway and (I don't think) we've kicked off a firmware uprev to fix it.  See  bug #717304 


Presumably this same problem ought to exist on other kernel versions.  Do we want to pick to 3.18, 3.14, 3.10, and 3.8 too?

It looks like we have older devices that use sbs-battery, so I will pick it to those old kernels.

Picks to all kernels landed.

Verified on Kevin (Kernel 4.4) with version 61.0.3138.0/9686.0.0 dev-channel 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7bb8603464f7ff793ca05a29a5f6452c63dc27ff

commit 7bb8603464f7ff793ca05a29a5f6452c63dc27ff
Author: Shawn Nematbakhsh <shawnn@chromium.org>
Date: Mon Sep 25 03:10:24 2017

CHROMIUM: power: sbs-battery: Prevent CAPACITY_MODE races

A subset of smart battery commands return charge or energy depending on
the CAPACITY_MODE bit setting of BatteryMode(). In order to
unambiguously read a charge or energy value, it is necessary to ensure
that CAPACITY_MODE is set as desired, and not changed for the duration
of the attribute read.

BUG= chromium:686942 
TEST=On kevin, spam reads to charge_full battery sysfs attribute while
performing suspend_stress_test, verify that the same value is always
returned.

Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ic39e8d7f982d7045a2da6bf6fe835c2c3434815c
Reviewed-on: https://chromium-review.googlesource.com/531760
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 28878159180029badf429ae844b6a78221707ee8)
Reviewed-on: https://chromium-review.googlesource.com/680674
Reviewed-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Commit-Queue: Jeffy Chen <jeffy.chen@rock-chips.com>
Tested-by: Jeffy Chen <jeffy.chen@rock-chips.com>

[modify] https://crrev.com/7bb8603464f7ff793ca05a29a5f6452c63dc27ff/drivers/power/sbs-battery.c