New issue
Advanced search Search tips

Issue 804495 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Add test to verify that Chrome reports suspend readiness

Project Member Reported by derat@chromium.org, Jan 22 2018

Issue description

 Issue 803727  tracked a regression where Chrome's screen-locking code would fail to acknowledge when the lock screen was up, resulting in powerd waiting 20 seconds for Chrome to confirm suspend readiness before timing out and suspending.

We should have some way to catch bugs like this. Unfortunately, it seems pretty tricky: different challenging-to-instrument parts of Chrome can delay suspend (screen lock, ARC, etc.), and powerd still suspends eventually even if Chrome fails to respond. Other clients like shill also register suspend delays, so we'd probably want to exercise them as well.

I'll think about this some more, but I'm all ears for suggestions too.
 

Comment 1 by tbroch@chromium.org, Jan 23 2018

Cc: mqg@chromium.org
My thoughts ...

1. Identifying failure:

1a) Could add parsing of,

0118/210402:WARNING:suspend_delay_controller.cc(205)] Timed out while waiting for suspend request 104136709 readiness confirmation for 1 delay(s): 104136707 (:1.87: chrome)

to autotest/files/client/cros/power/power_suspend.py 

CON: fragile

Could strengthen w/ more fragile parsing of positive responses,

[0123/125329:INFO:suspend_delay_controller.cc(137)] Announcing suspend request 89587713 with 3 pending delay(s) and 0 outstanding delay(s) from previous request
[0123/125329:INFO:suspend_delay_controller.cc(86)] Got notification that delay 89587713 (shill) is ready for suspend request 89587713 from :1.9
[0123/125330:INFO:daemon.cc(1425)] Chrome is using normal display mode
[0123/125330:INFO:suspend_delay_controller.cc(86)] Got notification that delay 89587716 (chrome) is ready for suspend request 89587713 from :1.56
[0123/125331:INFO:suspend_delay_controller.cc(86)] Got notification that delay 89587715 (trunksd) is ready for suspend request 89587713 from :1.22
[0123/125331:INFO:suspend_delay_controller.cc(223)] Notifying observers that suspend is ready

1b) could drop a nugget(s) in /run/power_manager/root to signify timestamps for start & stop of userland suspend and examine those in autotest.

PRO: could track this portion of suspend for regressions as a perf keyval

2. Simulating failure (AKA adding lockscreen to testing)

2a) new test
2b) incorporate lockscreen usage in power_UIResume.
2c) incorporate suspend into desktopui_ScreenLocker.


Comment 2 Deleted

Sign in to add a comment