Issue 458878 in chromium: Chrome says no battery exists, no battery indicator on screen, yet I've been on battery for 30 minutes

[chro...@googlecode.com]

Status: Unconfirmed
Owner: ----
Labels: Pri-2 Via-Wizard Type-Bug-Regression OS-Chrome

New issue 458878 by matt.sie...@gmail.com: Chrome says no battery exists,
no battery indicator on screen, yet I've been on battery for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

UserAgent: Mozilla/5.0 (X11; CrOS x86_64 6457.83.0) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36
Platform: 6457.83.0 (Official Build) stable-channel wolf

Steps to reproduce the problem:
1. Crosh battery_test
2. ://power
3. ://system

What is the expected behavior?
It would tell you about battery health, battery %, usage etc. However the
system currently claims there is no battery when I use battery_test command:
No test length specified. Defaulting to 300s
ls: cannot access /sys/class/power_supply/*/online: No such file or
directory
dirname: missing operand
Try 'dirname --help' for more information.
No battery found. Insert the battery and reboot the device.

Additionally, no battery icon is present in notification bar and the front
LED on the case is blinking orange, which it usually only does when it's in
critically low power state (only happened once before to me).

When I check ://power it claims there is no battery detected (please see
attached screen shots).

://system power_supply_info says this:
[0215/182537:INFO:power_supply.cc(211)] Using low battery time threshold of
0 secs and using low battery percent threshold of 2.5
[0215/182537:WARNING:power_supply.cc(323)] Found neither line power nor a
battery; assuming that line power is connected
Device: Line Power
path:
online: yes
type: Mains
enum type: AC
model name:
voltage (V): 0
current (A): 0
That is what it says after I've been on battery power for 30 minutes. I'm
not currently connected to AC Power and it can't seem to find the battery.
And yet I'm typing this to you on the very same Chromebook without AC power
plugged in and supposedly no battery.

What went wrong?
I have no idea. I was using the Chromebook as I normally do. I plugged it
into AC power (same adapter and wall outlet / surge protector combination
I've used for months) and when I woke it up from sleep the battery
indicator was gone. I attempted system update to .114 without improvement.
I then attempted hard reset x 2 without improvement. I then disabled some
new chrome extensions I had downloaded in the past week (although nothing
in the last few days and it's been working fine). I then powerwashed x 1
without improvement. I then powerwashed again and reverted to .93. That's
where I am now. I posted about the issue here and was told to come here
and post about the issue.

Did this work before? Yes Earlier today. I believe I was originally
on .93, updated to .114 after issue first presented itself, powerwashed
back to .93 now

Chrome version: 40.0.2214.93 Channel: stable
OS Version: 6457.83.0
Flash Version: Shockwave Flash 16.0 r0

I truly feel this is a software issue. I've been on battery power only (NO
AC power) for over 30 minutes and the Chromebook is acting absolutely
normally. I can't explain the power_supply_info or ://power reports and
they don't make sense unless the Chromebook would power down automatically.

Help me Obi Wan Kenobi... you're my only hope to escape having to send this
back to Dell and being without it for at least a week and change. :(

Attachments:
Screenshot 2015-02-15 at 6.29.05 PM.png 111 KB
Screenshot 2015-02-15 at 6.28.48 PM.png 86.4 KB

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #1 on issue 458878 by lmcart...@gmail.com: Chrome says no battery

exists, no battery indicator on screen, yet I've been on battery for 30
minutes
https://code.google.com/p/chromium/issues/detail?id=458878

See Issue #444435

[chro...@googlecode.com]

Comment #2 on issue 458878 by matt.sie...@gmail.com: Chrome says no battery

exists, no battery indicator on screen, yet I've been on battery for 30
minutes
https://code.google.com/p/chromium/issues/detail?id=458878

I'm confused. Is this something that I can fix by updating to the Beta
channel (as it looks like this was fixed in Beta)? Or is this a true
hardware issue? This issue seems to be different from #444435 if you look
at my reports from ://power and ://system power_supply_info

[chro...@googlecode.com]

Comment #3 on issue 458878 by lmcart...@gmail.com: Chrome says no battery

exists, no battery indicator on screen, yet I've been on battery for 30
minutes
https://code.google.com/p/chromium/issues/detail?id=458878

I was hoping I'd found a similar bug for you, but don't know how to tell,
myself. (Sorry for the confusion.)

[chro...@googlecode.com]

Updates:
Labels: Cr-OS-Kernel-Power Performance-Power

Comment #4 on issue 458878 by tiench...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #9 on issue 458878 by seahorse...@gmail.com: Chrome says no battery

exists, no battery indicator on screen, yet I've been on battery for 30
minutes
https://code.google.com/p/chromium/issues/detail?id=458878

Version 40.0.2214.115 (64-bit)
Platform 6457.107.0 (Official Build) stable-channel falco
Firmware Google_Falco.4389.92.0

Still showing up on Stable channel Falco. Any fixes in the works?

Attachments:
Screenshot 2015-03-01 at 9.10.35 PM.png 35.6 KB

[chro...@googlecode.com]

Comment #10 on issue 458878 by paolo.cl...@gmail.com: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

Some information which may be relevant or provide clues (based on
comparisons between Asus C300, where battery issue is identical as
described here) and Samsung Series 3 (where I have no issue with battery)

- in ://power, the Asus never showed a graph for Frequency State Data, from
day 1
- Asus makes a distinctive humming noise when on sleep, which I'd
originally attributed to keeping WiFi on, but having disabled option, now
know it's not that

[chro...@googlecode.com]

Updates:
Status: Untriaged
Labels: Cr-UI-Shell

Comment #11 on issue 458878 by michae...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

I just had the same problem on my Chromebook Pixel, 43.0.2357.19 (Official
Build) dev (64-bit).

No battery icon in the shelf status area or the status tray menu.

crosh> battery_test
No test length specified. Defaulting to 300 seconds.
[0418/152222:WARNING:power_supply.cc(533)] Found neither line power nor a

battery; assuming that line power is connected

No battery found.

In chrome://power, under "Battery charge", the entire line graph is at
-1.00, spanning 20 minutes. The battery discharge rate is 0.00 for the same
period.

The instant that I clicked the up arrow to increase the number of samples,
new data points appeared, and the battery icon appeared in the status area.
Also, battery_test works now:

crosh> battery_test 10
Battery is discharging (62.61% left)
Battery health: 92.71%
Please wait...
Battery discharged 0.07% in 10 second(s).

See screenshots with missing battery indicator, and then the results of
increasing the # of samples in chrome://power.

Attachments:
Screenshot 2015-04-18 at 3.21.31 PM.png 4.4 MB
Screenshot 2015-04-18 at 3.28.06 PM.png 378 KB

[chro...@googlecode.com]

Comment #12 on issue 458878 by de...@google.com: Chrome says no battery

exists, no battery indicator on screen, yet I've been on battery for 30
minutes
https://code.google.com/p/chromium/issues/detail?id=458878

> The instant that I clicked the up arrow to increase
> the number of samples, new data points appeared, and
> the battery icon appeared in the status area. Also,
> battery_test works now:

I don't see any way that interactions with chrome://power could've
triggered this and suspect a coincidence.

[chro...@googlecode.com]

Updates:
Cc: abod...@chromium.org
Labels: -Pri-2 Pri-1

Comment #15 on issue 458878 by michae...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

This is still an issue in 43.0.2357.52. There's no indication of my battery
level, signing out doesn't help. I rebooted and the battery indicator
returned (turns out I'm at 17%).

This bug has been open for 3 months, but I have to believe this is higher
than Pri-2.

Platform: 6946.38.0 (Official Build) beta-channel link

[chro...@googlecode.com]

Comment #16 on issue 458878 by de...@chromium.org: Chrome says no battery

exists, no battery indicator on screen, yet I've been on battery for 30
minutes
https://code.google.com/p/chromium/issues/detail?id=458878

#15: Please file a feedback report.

[chro...@googlecode.com]

Updates:
Labels: M-45

Comment #17 on issue 458878 by abod...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

Agreed. We really need to fix this.

[chro...@googlecode.com]

Updates:
Cc: de...@chromium.org rponn...@chromium.org a...@chromium.org
durga.be...@chromium.org

Comment #19 on issue 458878 by smbar...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

Issue 464316 has been merged into this issue.

[chro...@googlecode.com]

Updates:
Labels: Cr-OS-Firmware-EC

Comment #21 on issue 458878 by de...@chromium.org: Chrome says no battery

exists, no battery indicator on screen, yet I've been on battery for 30
minutes
https://code.google.com/p/chromium/issues/detail?id=458878

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #28 on issue 458878 by vap...@chromium.org: Chrome says no battery

exists, no battery indicator on screen, yet I've been on battery for 30
minutes
https://code.google.com/p/chromium/issues/detail?id=458878

Issue 458259 has been merged into this issue.

[chro...@googlecode.com]

Comment #30 on issue 458878 by bugd...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes

https://code.google.com/p/chromium/issues/detail?id=458878#c30

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/772156412f85c3aeed361dd84edb7556e56aa3c3

commit 772156412f85c3aeed361dd84edb7556e56aa3c3
Author: cernekee <cern...@chromium.org>
Date: Thu May 21 00:43:25 2015

Add Platform.BatteryAbsent histogram to track "missing battery icon" bug

We'll add an upstart job on the Chrome OS side to log whether the failure
is seen on each boot.

BUG=458878
R=jrbar...@chromium.org,vap...@chromium.org,seme...@chromium.org,ol...@chromium.org,ejca...@chromium.org,ishe...@chromium.org

Signed-off-by: Kevin Cernekee <cern...@chromium.org>

Review URL: https://codereview.chromium.org/1133493008

Cr-Commit-Position: refs/heads/master@{#330863}

[modify]
http://crrev.com/772156412f85c3aeed361dd84edb7556e56aa3c3/tools/metrics/histograms/histograms.xml

[chro...@googlecode.com]

Comment #32 on issue 458878 by rsch...@chromium.org: Chrome says no battery

exists, no battery indicator on screen, yet I've been on battery for 30
minutes
https://code.google.com/p/chromium/issues/detail?id=458878

This is currently happening on my Pixel on Beta. Please let me know if
there's any info I can provide to help debug, though I'm also not on dev
mode.

[chro...@googlecode.com]

Comment #33 on issue 458878 by rookris...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

Issue 492437 has been merged into this issue.

[chro...@googlecode.com]

Comment #34 on issue 458878 by aaboa...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

re: #33

That case seems a little different from this issue (red charging LED). But
since it's reported as always reproducible, it might be worth it to take a
look at that exact system.

[chro...@googlecode.com]

Comment #35 on issue 458878 by cerne...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

> re: #33
> That case seems a little different from this issue (red charging LED).

FWIW, my charging LED turned red whenever the charge state machine was in
the error state. Then it passed through the reinit state and turned
green/amber again.

The unit in bug 492437 is en route to MTV for analysis.

Other updates:

At https://code.google.com/p/chromium/issues/detail?id=464316#c17 smbarber
reported some unusual output from "ectool battery" on his failing unit:

Battery info:
OEM name:
Model number:
Chemistry :
Serial number:
Design capacity: 0 mAh
Last full charge: 0 mAh
Design output voltage 0 mV
Cycle count 0
Present voltage 0 mV
Present current 0 mA
Remaining capacity 0 mAh
Flags 0x04 DISCHARGING

Playing around with the firmware-link-2695.B branch of the EC firmware, I
was not able to find a single point of failure that reproduces this
symptom. The OEM name and model values are written into the EC_MEMMAP_*
registers when the charge state machine starts up:

charge_state_machine_task()
-> state_init()
-> update_battery_info()
-> battery_* functions (to populate each field)

AFAICT, no other function writes to these addresses, and the host reads
them directly over LPC.
update_battery_info() sets EC_MEMMAP_BATTERY_VERSION = 1 at the end of the
function. If update_battery_info() never runs, then we don't even get any
output from the command:

localhost ~ # ectool battery
Battery version 0 is not supported
localhost ~ #

So we can conclude that update_battery_info() is running, but somehow the
fields are either initially populated with zeroes, or are zeroed out later.

To test "initially populated with zeroes" I instrumented
i2c_transmit_receive() so that the first N transactions would use a bogus
I2C address and time out. With N=30 some of the "ectool battery" fields
still remained populated, which tells me that seeing all zeroes/blanks
probably means that the battery's I2C bus was completely non-responsive.
It is unclear how the system can get into this state, but
immediately "heal" itself after a simple EC reset. It might point to an
issue with the I2C controller rather than the battery.

I don't have a working theory on "zeroed out later."

As for the more general symptom of "ACPI: Battery Slot [BAT0] (battery
absent)" in the kernel boot log, leading to a missing battery icon: I could
reproduce this by forcing state_common() to fail consistently, but
occasional failures (even as frequent as 1 out of 100 transactions =>
reinit several times a minute) did not get the EC wedged in a "battery
absent" state. If the occasional failure coincided with a system boot,
then the kernel would detect "battery absent" but it would fix itself on a
Linux reboot (no EC reboot).

In bug 492721 there is some discussion of capturing the EC console log to
help in diagnosing these sorts of problems. It might also be helpful to
log any nonzero ctx->curr.error values when returning from state_common()
or transitioning states, as that provides a different flag for each failure
mode.

I am running some more power cycle tests overnight in the hopes of
reproducing the original issue on my board.

[chro...@googlecode.com]

Comment #36 on issue 458878 by cerne...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

My first attempt at power cycle tests (Linux reboot, no EC reboot) did not
yield any results. Now I'm trying EC reboots every ~30s while toggling the
AC power on and off every 5-25 seconds. If that doesn't help, I might
throw random suspend/resume events into the mix too.

Over on the product forums, a post says:

> This happens (to me) every time the stable channel updates to a new major
> release.
[...]
> I fixed it using a hard reset

https://productforums.google.com/forum/#!msg/chromebook-central/GlDwQmty-UM/WP8sF9g-0aEJ

Perhaps this could be triggered by the EC software sync during firmware
updates. But how is that different from any other EC reset?

[chro...@googlecode.com]

Comment #37 on issue 458878 by cerne...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

> The unit in bug 492437 is en route to MTV for analysis.

> I assume the battery probably isn't responding via I2C, though we
> could check that

On this unit, the charger LED stays off for ~28 seconds after an EC reset,
then turns solid red. Pulling out the charger causes the unit to lose
power immediately.

The EC console says:

[06/03 17:15:10] [25.212421 Charge state init -> error]
[...]
[06/03 17:15:24] [38.218885 Charge error: flag[00000000 ->
10011111110], ac 1, charger (err), battery (err)

which decodes to:

0: F_CHARGER_INIT (1 << 0) /* Charger initialization */
1: F_CHARGER_VOLTAGE (1 << 1) /* Charger maximun output voltage */
1: F_CHARGER_CURRENT (1 << 2) /* Charger maximum output current */
1: F_BATTERY_VOLTAGE (1 << 3) /* Battery voltage */
1: F_BATTERY_CURRENT (1 << 4) /* Battery charging current */
1: F_DESIRED_VOLTAGE (1 << 5) /* Battery desired voltage */
1: F_DESIRED_CURRENT (1 << 6) /* Battery desired current */
1: F_BATTERY_TEMPERATURE (1 << 7) /* Battery temperature */
0: F_BATTERY_MODE (1 << 8) /* Battery mode */
0: F_BATTERY_CAPACITY (1 << 9) /* Battery capacity */
1: F_BATTERY_STATE_OF_CHARGE (1 << 10) /* State of charge, percentage */

i2cscan reports that the bus is wedged:

> i2cscan
Scanning 0 batt_chg: port busy (SDA=0, SCL=0)
Scanning 1 lightbar...........................................
0x54.

0x56....................................................................................
Scanning 5 thermal.........
0x10.........................................................
0x82..
0x86.
0x88..
0x8c.....
0x96.
0x98.....................
0xc2..............................

It is somewhat curious that some of the reads, like F_BATTERY_MODE,
succeed, but others fail. I'll run some more experiments to see if I can
make any sense of this (and maybe figure out if some specific event is
hanging the bus).

At first glance I don't see any evidence of swollen batteries, burned
components, or other physical damage - but I'll ask the EE lab to take a
closer look.

[chro...@googlecode.com]

Comment #38 on issue 458878 by bugd...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes

https://code.google.com/p/chromium/issues/detail?id=458878#c38

The following revision refers to this bug:

https://chromium.googlesource.com/chromiumos/platform2/+/db808bbc22a5b03306ed65e463cb6fae5db49fde

commit db808bbc22a5b03306ed65e463cb6fae5db49fde
Author: Kevin Cernekee <cern...@chromium.org>
Date: Tue May 19 22:30:03 2015

init: send-kernel-errors: Add kernel error reporting via UMA

On occasion we may want to scan the kernel's startup log for specific
strings that indicate faults during the boot process. We already
have a warn_collector daemon that constantly scans the kernel log
in the background, but it isn't well-suited for this task for three
reasons:

- It monitors the log file (on disk), so it doesn't have an easy way
to tell where the current boot started. It gets around this
problem by ignoring all messages that were logged before the daemon
was started. So as it stands, it won't catch any errors that pop
up during boot.

- It is designed to look for standard Linux WARN_ON-style messages,
which include a crash signature and backtrace.

- In many cases we need to be able to find the ratio of good:bad
units, not just the raw number of occurrences.

So, the most straightforward solution is to add another send-* upstart
job that calls metrics_client for each string that we want to monitor.

BUG=chromium:458878
TEST=boot test with both good and bad results, then peek into UMA to
see stats

Change-Id: Ic8e30d7a52e6622e2d555ef818fe11e132046097
Signed-off-by: Kevin Cernekee <cern...@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/272278
Reviewed-by: Eric Caruso <ejca...@chromium.org>

[add]
http://crrev.com/db808bbc22a5b03306ed65e463cb6fae5db49fde/init/send-kernel-errors.conf

[chro...@googlecode.com]

Updates:
Cc: dbern...@chromium.org

Comment #39 on issue 458878 by cerne...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes

https://code.google.com/p/chromium/issues/detail?id=458878

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #43 on issue 458878 by cerne...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

> It is somewhat curious that some of the reads, like F_BATTERY_MODE,
> succeed, but others fail.

The broken unit mentioned in #37 somehow healed itself and is now charging
normally. So it looks like something (probably the battery) locked up the
I2C bus and then it recovered after we started messing with the unit.

FWIW the steps I took immediately prior to "healing" were:

- Transition to dev mode via <recovery> <ctrl-d>
- Dump the AP firmware image via servo (so I'd have a record of the unit's
original state, prior to tinkering with it)

After it healed, I soldered wires onto the battery connector and grounded
SDA and SCL, then monitored the EC console. This produced symptoms that
were identical to the original state of the unit: the charging LED was
red, "Charge state init -> error" in the log, and "Charge error:
flag[00000000 -> 10011111110], ac 1, charger (err), battery (err)".

As it turns out, the zero bits are just an innocuous side effect of how
state_common() works:

- Midway through the function, the function abruptly returns if
curr->error indicates any battery errors. This prevents the F_BATTERY_MODE
and F_BATTERY_CAPACITY flags from being set, because the code that queries
those parameters never runs.

- At the top of state_common(), charger_post_init() is skipped if the "AC
present" GPIO has not changed state since the last try. On the initial run
of state_common(), curr->ac=1 and prev->ac=0, so charger_post_init() runs
and F_CHARGER_INIT is set. But our "Charge error" string doesn't get
printed until the next run through the loop. During the second run,
curr->ac=1 and prev->ac=1, and curr->error is set to 0 initially, so
charger_post_init() is skipped and F_CHARGER_INIT remains clear.

> init: send-kernel-errors: Add kernel error reporting via UMA

This should be hitting beta channel shortly, so we can quantify the scope
of the problem and see which boards are most affected.

[chro...@googlecode.com]

Updates:
Cc: Kusc...@chromium.org

Comment #46 on issue 458878 by cerne...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

I was just reviewing the two jamescook (?) logs (5781282972, 5781325536)
after receiving a new report (5782302340) from rschoen this morning.
Ryan's unit also logged "battery absent" right after waking up from dark
resume, so maybe there is a pattern here.

I've had a test rack running for a couple of weeks; it is toggling power
and rebooting (normal + EC) constantly, but it isn't exercising dark
resume. There has only been one anomaly (#44) and it doesn't look like a
very good lead.

I'll tweak the dark resume timeout and see how to replicate these
conditions. Thanks for the reports.

BTW, if you're on dev channel, I think we'll receive EC logs as part of
your feedback reports now that bug 492721 has been completed.

[chro...@googlecode.com]

Comment #47 on issue 458878 by chiran...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

You can run 'activate_short_dark_resume' to make dark resumes trigger more
frequently.

[chro...@googlecode.com]

Comment #48 on issue 458878 by cerne...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

jamescook, kuscher - I found another report that might be more closely
related to the UI presentation of the charge level than communication with
the battery:

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

According to the powerd logs, this doesn't look related to dark resume.
This is a nyan_blaze, not a link. It looks like the battery was drained to
0%, and maybe that is being interpreted as "no battery" until it builds up
a little bit of a charge:

[0707/140555:WARNING:power_supply.cc(877)] Ignoring probably-bogus zero
battery percentage
[0707/140555:INFO:daemon.cc(772)] On AC (Mains) with battery at 0%,
0.000/3.132Ah at 0.225A, 0s until empty (calculating)
[0707/140600:WARNING:power_supply.cc(877)] Ignoring probably-bogus zero
battery percentage
[0707/140600:INFO:daemon.cc(772)] On AC (Mains) with battery at 0%,
0.000/3.132Ah at 0.225A, 0s until empty
[0707/140800:INFO:daemon.cc(772)] On AC (Mains) with battery at 0%,
0.010/3.132Ah at 1.534A, 39s until empty (0s until shutdown)

The previous session looks worse, although I'm having trouble following or
trusting the timestamps. Does "1231/1900xx" mean the RTC lost power and
reset to the 1970-01-01 UNIX epoch -0500?

This Chromebook apparently doesn't get used very often and might be left
unplugged for extended periods.

[chro...@googlecode.com]

Comment #49 on issue 458878 by Kusc...@chromium.org: Chrome says no battery

exists, no battery indicator on screen, yet I've been on battery for 30
minutes
https://code.google.com/p/chromium/issues/detail?id=458878

The latest one sounds different to me. In the first report from james he
used a Pixel and it was not empty at all I believe (james to confirm)

[chro...@googlecode.com]

Comment #50 on issue 458878 by jame...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

Yeah, my Pixel was not empty.

You might already know this, but there is a feedback category for battery
indicator issues, which might help find additional reports:

https://feedback.corp.google.com/product/208/neutron?lView=td&lTagFamily=%23issue&lTagSearch=MissingBatteryIndicator&lTag=%23issue%3EDisplay%3EMissingBatteryIndicator&lRSort=1&lROrder=2&lRFilter=1

[chro...@googlecode.com]

Comment #52 on issue 458878 by cerne...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

I haven't updated this bug for a while, but in recent weeks some progress
has been made.

The first big clue arrived about a month ago, when matthewyuan supplied a
Pixel 1 that was in the bad state (BatteryAbsent true, no icon). We opened
the unit up while it was live, and cut wires/traces until we reached a
point where the issue was narrowed down to the EC. tek00124.png shows that
SCL was held low before and after each transaction, and the rise times
looked a bit unhealthy. Nothing but the EC was on the bus at this point.

The EC is manufactured by TI, so we approached TI to ask how this could
have happened. TI pointed us to an erratum involving the ESD protection
circuits on the 5v-tolerant pads (which include both I2C lines). The
symptoms are not an exact match for the observed behavior; in particular,
TI has only seen the latch-up above 85 degrees C, while most of the problem
reports we've seen have happened when the unit was cold. However, it may
still be a possibility.

Reviewing ~10 alt-shift-I feedback reports from link users, the general
pattern often looks like this:

1) Unit is on battery power, no AC.
2) Suspend the unit by closing the lid.
3) A few hours pass, and the OS wakes up for dark resume.
4) In dark resume, the system decides to shut down to save battery life.
5) Many hours pass. Presumably the EC enters hibernate mode.
6) User opens the lid the next morning (or a few days later), and sees a
missing battery icon on boot. AC has still not been connected.
7) Sometimes this fixes itself, but often it doesn't.

I have run a number of long-term stress tests involving EC hibernation and
EC resets, but none of them have reproduced the bug.

I have also tried many combinations of GPIO settings (open drain, pullup,
pulldown, drive strengths, etc.) to see if any software (mis)configuration
could produce a waveform similar to what we captured from the bad unit.
Nothing was found.

At this point it seems that our best option is to backport the
i2c_unwedge() code from ToT, and monitor the UMA stats to assess whether
that helps. Some of the reasons we decided to try this are:

a) The unwedge code is a known quantity; it has been deployed on all modern
Chromebooks and is unlikely to have side effects.

b) TI suspects that changing GPIO modes (e.g. AFSEL) and wiggling the pin
may be one way to repair the ESD latch-up condition.

c) It is possible that newer Chromebooks running the same LM4 EC do not
experience this problem because they do have i2c_unwedge() in their
firmware. i2c_unwedge() runs any time an I2C error is seen, so maybe this
condition is happening on the newer Chromebooks but it is getting repaired
automatically.

d) We have observed that some units recover on their own from the error
condition, and we don't have a good idea what causes this behavior. It is
possible that merely wiggling the affected lines is enough to return the
chip to normal behavior.

Some reasons why this might NOT be helpful:

e) If it works, we still won't know the root cause. That is not ideal.

f) The current unwedge code mostly gives up if SCL is stuck low. Maybe we
want to be more aggressive about driving it, in this case.

g) I backported the i2cwedge command and played with it for a while, but I
wasn't actually able to show that any peripheral on this bus can get
wedged. So i2c_unwedge() might not actually serve its primary purpose on
link. Some I2C peripherals can be convinced to hold e.g. SDA low forever,
by abruptly halting a transaction. SMBus peripherals have timeouts, and in
my testing, I wasn't able to get any of the chips on this I2C bus to wedge
the bus for more than ~40ms.

The other thing I observed in testing is that the initial call to
i2c_unwedge() inadvertently causes glitches on both SCL and SDA when the
GPIOs are being reconfigured. Subsequent calls did not cause glitches. If
SCL is stuck low, i2c_unwedge() doesn't actually try to wiggle any pins,
but maybe one of these glitches is accidentally fixing the latch-up
condition.


Attachments:
tek00124.png 36.0 KB

[chro...@googlecode.com]

Comment #54 on issue 458878 by bugd...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes

https://code.google.com/p/chromium/issues/detail?id=458878#c54

The following revision refers to this bug:

https://chromium.googlesource.com/chromiumos/platform/ec/+/84dbc0f161cee9080f90762160ea9cf00301dde7

commit 84dbc0f161cee9080f90762160ea9cf00301dde7
Author: Kevin Cernekee <cern...@chromium.org>
Date: Mon Aug 17 23:01:34 2015

lm4: Make gpio_set_flags() honor GPIO_OPEN_DRAIN

Currently gpio_set_flags() only enables ODR mode if the GPIO_OPEN_DRAIN
flag is set in the gpio_list entry. Since we need to be able to enable
and disable ODR mode dynamically from the unwedge code, check both
flags (from the caller) and g->flags (from the gpio config table).

Note that ToT only checks the flags passed in from the caller, but
if we used that scheme it might require changing additional call sites
(e.g. SPI GPIO configuration).

BUG=chromium:458878
BRANCH=link
TEST=manual

Change-Id: I4e60db30ec5333f80e5a807709d01cfdb2fbdbbb
Signed-off-by: Kevin Cernekee <cern...@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295095
Reviewed-by: Randall Spangler <rspa...@chromium.org>

[modify]
http://crrev.com/84dbc0f161cee9080f90762160ea9cf00301dde7/chip/lm4/gpio.c

[chro...@googlecode.com]

Comment #57 on issue 458878 by bugd...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes

https://code.google.com/p/chromium/issues/detail?id=458878#c57

The following revision refers to this bug:

https://chromium.googlesource.com/chromiumos/platform/ec/+/86e43a46b2b1d452d74a64fae4f8d583ba04cc9d

commit 86e43a46b2b1d452d74a64fae4f8d583ba04cc9d
Author: Kevin Cernekee <cern...@chromium.org>
Date: Sun Aug 16 22:23:18 2015

Backport i2cwedge command

This permits testing of the backported unwedge logic.

BUG=chromium:458878
BRANCH=link
TEST=manual

Change-Id: Ib68ee53254e2e8003a3b38d81501338fe337c9c3
Signed-off-by: Kevin Cernekee <cern...@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295099

Reviewed-by: Randall Spangler <rspa...@chromium.org>

[modify]

http://crrev.com/86e43a46b2b1d452d74a64fae4f8d583ba04cc9d/chip/lm4/i2c.c
[add]
http://crrev.com/86e43a46b2b1d452d74a64fae4f8d583ba04cc9d/common/i2c_wedge.c
[modify]
http://crrev.com/86e43a46b2b1d452d74a64fae4f8d583ba04cc9d/include/i2c.h
[modify]
http://crrev.com/86e43a46b2b1d452d74a64fae4f8d583ba04cc9d/board/link/board.h
[modify]
http://crrev.com/86e43a46b2b1d452d74a64fae4f8d583ba04cc9d/common/build.mk

[chro...@googlecode.com]

Comment #58 on issue 458878 by bugd...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes

https://code.google.com/p/chromium/issues/detail?id=458878#c58

The following revision refers to this bug:

https://chromium.googlesource.com/chromiumos/platform/ec/+/352afa8e2ea3f51b8ae1d62d50e67a545746d1a7

commit 352afa8e2ea3f51b8ae1d62d50e67a545746d1a7
Author: Kevin Cernekee <cern...@chromium.org>
Date: Fri Aug 21 00:36:51 2015

i2cwedge: Don't wiggle SDA on every bit

Re-asserting SDA on every bit results in a very strange-looking
waveform, and it may confuse some devices.

BUG=chromium:458878
BRANCH=link
TEST=manual

Change-Id: I443251eac0fabfd893135212723691f148abd9ed
Signed-off-by: Kevin Cernekee <cern...@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295210

Reviewed-by: Randall Spangler <rspa...@chromium.org>

[modify]

http://crrev.com/352afa8e2ea3f51b8ae1d62d50e67a545746d1a7/common/i2c_wedge.c

[chro...@googlecode.com]

Comment #56 on issue 458878 by bugd...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes

https://code.google.com/p/chromium/issues/detail?id=458878#c56

The following revision refers to this bug:

https://chromium.googlesource.com/chromiumos/platform/ec/+/aa8e6b75674a6a18fccf715d30bca385f5d5864f

commit aa8e6b75674a6a18fccf715d30bca385f5d5864f
Author: Kevin Cernekee <cern...@chromium.org>
Date: Sun Aug 16 21:57:36 2015

lm4: Backport i2c_unwedge() logic

This causes the driver to wiggle the scl/sda lines after a transaction
error, if the lines are not both high.

BUG=chromium:458878
BRANCH=link
TEST=manual

Change-Id: I3dc2115ce80d24c835cfbf6fdbf56b7f1f9460fb
Signed-off-by: Kevin Cernekee <cern...@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295097

Reviewed-by: Randall Spangler <rspa...@chromium.org>

[modify]

http://crrev.com/aa8e6b75674a6a18fccf715d30bca385f5d5864f/chip/lm4/i2c.c
[modify]
http://crrev.com/aa8e6b75674a6a18fccf715d30bca385f5d5864f/include/i2c.h

[chro...@googlecode.com]

Comment #55 on issue 458878 by bugd...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes

https://code.google.com/p/chromium/issues/detail?id=458878#c55

The following revision refers to this bug:

https://chromium.googlesource.com/chromiumos/platform/ec/+/c1f7a09cfd933beb2acf0d8142e7393486619f1b

commit c1f7a09cfd933beb2acf0d8142e7393486619f1b
Author: Kevin Cernekee <cern...@chromium.org>
Date: Sun Aug 16 21:37:48 2015

lm4: Backport i2c utility functions

Add support for raw mode and for toggling scl/sda manually. This
is not an exact match for the code in ToT because a lot of
infrastructure is missing in the old link branch, particularly
gpio_config_pins and common/{i2c,gpio}.c.

BUG=chromium:458878
BRANCH=link
TEST=compile-tested only

Change-Id: I3ffea8aeec0c87d849bd9c3ac687542d6f2013dd
Signed-off-by: Kevin Cernekee <cern...@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295096

Reviewed-by: Randall Spangler <rspa...@chromium.org>

[modify]

http://crrev.com/c1f7a09cfd933beb2acf0d8142e7393486619f1b/chip/lm4/i2c.c
[modify]
http://crrev.com/c1f7a09cfd933beb2acf0d8142e7393486619f1b/include/i2c.h

[chro...@googlecode.com]

Updates:
Labels: merge-merged-firmware-link-2695.B

Comment #53 on issue 458878 by bugd...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes

https://code.google.com/p/chromium/issues/detail?id=458878#c53

The following revision refers to this bug:

https://chromium.googlesource.com/chromiumos/platform/ec/+/fb98259abd8a52978f9bca47273b226af802cc2e

commit fb98259abd8a52978f9bca47273b226af802cc2e
Author: Kevin Cernekee <cern...@chromium.org>
Date: Sun Aug 16 21:26:19 2015

link: Add definitions for I2C GPIO pins

We're going to backport a couple of functions that use these.

This patch will cause the I2C0 GPIOs to lose their power-on pinmux
defaults, but that's OK because chip/lm4/i2c.c explicitly sets them
up anyway.

BUG=chromium:458878
BRANCH=link
TEST=manual

Change-Id: I78686f51aac29070911b70f301b0203c1af21009
Signed-off-by: Kevin Cernekee <cern...@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295094

Reviewed-by: Randall Spangler <rspa...@chromium.org>

[modify]

http://crrev.com/fb98259abd8a52978f9bca47273b226af802cc2e/include/i2c.h
[modify]
http://crrev.com/fb98259abd8a52978f9bca47273b226af802cc2e/board/link/board.c
[modify]
http://crrev.com/fb98259abd8a52978f9bca47273b226af802cc2e/board/link/board.h

[chro...@googlecode.com]

Updates:
Labels: -M-45 -Merge-Approved-44 -Hotlist-Merge-Approved M-47

Comment #63 on issue 458878 by josa...@chromium.org: Chrome says no battery

exists, no battery indicator on screen, yet I've been on battery for 30
minutes
https://code.google.com/p/chromium/issues/detail?id=458878

Do we have a depending bugs to resolve problems and packages needed for
c#61?

[chro...@googlecode.com]

Updates:
Cc: lafo...@chromium.org

Comment #64 on issue 458878 by cerne...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

josafat - I suppose you're wondering if this is something we need for M46?
At this point it's probably a bit late...

Bug 523571 is tracking the build issues.


As a side note, since this message has been showing up on every single one
of my bugs:

> The current issue owner maybe inactive (i.e. hasn't fixed an issue in the
> last 30 days).

a) Several projects have moved to the partner tracker and buganizer, so the
inactivity checker should check those too.

b) You'll probably want to use "may be" rather than "maybe", as the latter
is an adverb.

[chro...@googlecode.com]

Comment #68 on issue 458878 by w...@chromium.org: Chrome says no battery

exists, no battery indicator on screen, yet I've been on battery for 30
minutes
https://code.google.com/p/chromium/issues/detail?id=458878

Re #52: When you say "sometimes it fixes itself, sometimes it doesn't" in
(7), what do you mean? My device is resolutely stuck without a battery
indicator, across several shutdowns and reboots at this point - is that
expected?

[chro...@googlecode.com]

Comment #69 on issue 458878 by cerne...@chromium.org: Chrome says no

battery exists, no battery indicator on screen, yet I've been on battery
for 30 minutes
https://code.google.com/p/chromium/issues/detail?id=458878

Might be a different problem.

If you were in MTV I'd take a look in person, but in this case, you're
probably better off just trying a hard (refresh+power) reset first.

If that doesn't work, we can probe the I2C bus in MTV and see if the
symptoms match. I think Techstop will exchange your unit for a Pixel 2?
If you go down that path, I'd appreciate it if you could ship the bad unit
to me.