New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 603824 link

Starred by 1 user

Issue metadata

Status: Duplicate
Owner:
Closed: Apr 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

power_Resume: inaccurate estimate of firmware_ec resume time

Project Member Reported by jcliang@chromium.org, Apr 15 2016

Issue description

Version: any version after chromeos release 8142.0.0
OS: Chrome OS

What steps will reproduce the problem?
(1) find a board with proven resume time less than 1 second
(2) run power_Resume
(3) check the seconds_system_resume_firmware_ec field

What is the expected output?

seconds_system_resume_firmware_ec should be small

What do you see instead?

seconds_system_resume_firmware_ec is greater than 1 second

Please use labels and text to provide additional information.

This CL: https://chromium.googlesource.com/chromiumos/overlays/portage-stable/+/a562e11be8e82fed6e6e91ac38cd8fc1d7872879 upreved util-linux which changed the hwclock command, which affected the measured resume latency in powerd_suspend.
 

Comment 1 by derat@chromium.org, Apr 15 2016

Cc: derat@chromium.org
Owner: jwer...@chromium.org
Status: Assigned (was: Available)
I... don't know what I have to do with this metric. :-)

It looks like it's in power_suspend.py. Julius, I think that you wrote this, right?
Cc: jwer...@chromium.org
Owner: dbasehore@chromium.org
I think this is a known issue that Derek is already working on somewhere.
This also does this while playing .swf media playback on the fly as well, if the system locks itself for long periods of time, the resume process will take as long enough itself also.
Mergedinto: 602532
Status: Duplicate (was: Assigned)

Sign in to add a comment