skate unable to detect AC power
Reported by
jrbarnette@chromium.org,
Feb 28 2017
|
|||
Issue description
Browsing test logs for various daisy_skate devices, I
found one device with a distinct failure mode of concern:
* A new build, R57-9202.37.0, is installed on the DUT.
* During routine post-install verification, the DUT
reports that it has no AC power.
* Logs of failure claim the battery is discharging.
* Repair triggers, and installs the repair image,
R57-9202.18.0.
* After installing the alternate build, the DUT reports
working AC power.
If this problem can be replicated, it indicates that on
daisy_skate, the .37 software is unable to detect AC power,
at least sometimes. It could also mean that the device
is unable to charge.
The skate design is similar to spring so those systems may
also be affected.
The symptom is somewhat sparse, so it's possible that the
problem is intermittent. This could be likely: the .37.0
build is now the standard repair image for daisy_skate, so
if this problem were widespread, we'd be suffering an outage
for skate in the test lab.
,
Feb 28 2017
Two separate DUTs experienced the same problem for that build:
2017-02-28 00:52:12 OK http://cautotest/tko/retrieve_logs.cgi?job=/results/hosts/chromeos4-row9-rack6-host3/1848812-provision/
2017-02-28 00:50:43 OK http://cautotest/tko/retrieve_logs.cgi?job=/results/hosts/chromeos4-row9-rack6-host3/1848808-repair/
2017-02-28 00:50:27 -- http://cautotest/tko/retrieve_logs.cgi?job=/results/hosts/chromeos4-row9-rack6-host3/1848806-reset/
2017-02-28 00:31:32 -- http://cautotest/tko/retrieve_logs.cgi?job=/results/103901189-chromeos-test/
2017-02-28 00:31:09 OK http://cautotest/tko/retrieve_logs.cgi?job=/results/hosts/chromeos4-row9-rack6-host3/1848757-reset/
This is the reference to the suite job in the AFE:
https://ubercautotest.corp.google.com/afe/#tab_id=view_job&object_id=102897888
,
Feb 28 2017
I've checked logs. The .37.0 build became the repair build for both spring and skate this morning at 4:00 AM. So, if this build is going to start causing repair failures, it probably hasn't (yet) had enough time. If this problem is real, we could be able to see it in logs as early as tomorrow.
,
Feb 28 2017
vpalatin@ is this something you would look at? If not, please point us to someone who can.
,
Feb 28 2017
+derat I was originally thinking this must be something in the EC as that should be handling the charging behavior, however in the case this is something up the stack Dan might have some ideas as to if anything recently in power_manager could lead to flaky charging? I don't see anything suspicious in the 3.8 kernel in the last 3 months, and power_manager only seems to have added some stats in December which is not very suspicious either :-/.
,
Feb 28 2017
How do we detect AC power during repair? Does that come from powerd (or power_supply_info) or does it get read directly from sysfs?
,
Feb 28 2017
> How do we detect AC power during repair? Does that come from > powerd (or power_supply_info) or does it get read directly from sysfs? We run power_supply_info, and parse the output. Here's a sample from the logs: 02/23 01:35:10.327 INFO | repair:0327| Verifying this condition: The DUT is plugged in to AC power 02/23 01:35:10.328 DEBUG| ssh_host:0284| Running (ssh) 'power_supply_info' 02/23 01:35:10.707 DEBUG| base_utils:0280| [stdout] Device: Line Power 02/23 01:35:10.708 DEBUG| base_utils:0280| [stdout] path: 02/23 01:35:10.708 DEBUG| base_utils:0280| [stdout] online: no 02/23 01:35:10.709 DEBUG| base_utils:0280| [stdout] type: 02/23 01:35:10.709 DEBUG| base_utils:0280| [stdout] enum type: Disconnected 02/23 01:35:10.709 DEBUG| base_utils:0280| [stdout] voltage (V): 0 02/23 01:35:10.709 DEBUG| base_utils:0280| [stdout] current (A): 0 02/23 01:35:10.710 DEBUG| base_utils:0280| [stdout] max voltage (V): 0 02/23 01:35:10.710 DEBUG| base_utils:0280| [stdout] max current (A): 0 02/23 01:35:10.710 DEBUG| base_utils:0280| [stdout] active source: 02/23 01:35:10.711 DEBUG| base_utils:0280| [stdout] available sources: 02/23 01:35:10.711 DEBUG| base_utils:0280| [stdout] supports dual-role: no 02/23 01:35:10.711 DEBUG| base_utils:0280| [stdout] Device: Battery 02/23 01:35:10.711 DEBUG| base_utils:0280| [stdout] path: /sys/class/power_supply/sbs-20-000b 02/23 01:35:10.712 DEBUG| base_utils:0280| [stdout] vendor: SMP-COS27 02/23 01:35:10.712 DEBUG| base_utils:0280| [stdout] model name: OC1 02/23 01:35:10.712 DEBUG| base_utils:0280| [stdout] serial number: 018c 02/23 01:35:10.713 DEBUG| base_utils:0280| [stdout] state: Discharging 02/23 01:35:10.713 DEBUG| base_utils:0280| [stdout] voltage (V): 12.203 02/23 01:35:10.713 DEBUG| base_utils:0280| [stdout] energy (Wh): 27.75 02/23 01:35:10.713 DEBUG| base_utils:0280| [stdout] energy rate (W): 7.26078 02/23 01:35:10.714 DEBUG| base_utils:0280| [stdout] current (A): 0.595 02/23 01:35:10.714 DEBUG| base_utils:0280| [stdout] charge (Ah): 2.483 02/23 01:35:10.714 DEBUG| base_utils:0280| [stdout] full charge (Ah): 2.52 02/23 01:35:10.714 DEBUG| base_utils:0280| [stdout] full charge design (Ah): 2.7 02/23 01:35:10.714 DEBUG| base_utils:0280| [stdout] percentage: 98.5317 02/23 01:35:10.715 DEBUG| base_utils:0280| [stdout] display percentage: 100 02/23 01:35:10.715 DEBUG| base_utils:0280| [stdout] technology: Li-ion 02/23 01:35:10.717 ERROR| repair:0332| Failed: The DUT is plugged in to AC power
,
Mar 1 2017
It looks like 9202.18.0 was built at 2017-02-06 21:05, while 9202.37.0 was built at 2017-02-22 21:05. There weren't any changes to power_supply_info in that window, and I think that the last change that could've modified its behavior was https://chromium-review.googlesource.com/c/423233/ on January 12. I can add a --verbose flag to power_supply_info that we could use to debug further (it'd probably be useful to include this in feedback reports too -- I've filed issue 697288 against myself), but I'm guessing that this is just what's present in sysfs when power_supply_info reads from it.
,
Mar 1 2017
On the kernel side, spring and skate use a slightly different configuration (actually more for the battery info than the AC charger): the battery info are read through the EC using a limited I2C passthrough and the charger info are returned by the cros_ec-charger driver, but as mentioned by Bernie neither the config nor the driver code has changed for years. |
|||
►
Sign in to add a comment |
|||
Comment 1 by jrbarnette@chromium.org
, Feb 28 2017