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

Issue 781884 link

Starred by 1 user

Issue metadata

Status: Fixed
Merged: issue 781060
Owner:
Last visit > 30 days ago
Closed: Nov 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

A zero-to-nonzero regression in graphics_VTSwitch at 32530001007700000:32530001007800000

Project Member Reported by pwang@chromium.org, Nov 6 2017

Issue description

graphics_VTSwitch regression on Link only.
Test: ChromeOS_Graphics/cros-link/graphics_VTSwitch/Failures
Value: 1.0
Point ID: 32530001007800000
Time added: 2017-10-29T22:30:16.000Z
ChromeOS Version range: 64.10077.0.0 - 64.10078.0.0 
Chrome Version: 64.0.3253.0 

https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg1_zz2AgM
 
All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=781884

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=fdaa268a40a54b5700731c8eebfa1661173922077e216c57a8d401c06647b619


Bot(s) for this bug's original alert(s):

cros-link

Comment 2 by pwang@chromium.org, Nov 6 2017

Cc: dbehr@chromium.org pwang@chromium.org ihf@chromium.org
Labels: Gfx-Guard
Owner: pwang@chromium.org
Status: Started (was: Untriaged)
None of CL between CrOS 10077.0.0~10078.0.0 seems like the root cause.
https://crosland.corp.google.com/log/10077.0.0..10078.0.0

Will try flash the image on DUT to confirm it.

Comment 3 by pwang@chromium.org, Nov 6 2017

Based on the result of manually flash link and test. 
R64-10077 failed but R64-10076 is passing on link.
https://crosland.corp.google.com/log/10076.0.0..10077.0.0

It seems the mesa update might be the root cause.
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/4540d37c6974d2f31bc5e596a272c3804fe12c96

Comment 4 by pwang@chromium.org, Nov 6 2017

Mergedinto: 781060
Status: Duplicate (was: Started)

Comment 5 by dbehr@chromium.org, Nov 7 2017

I would not blame it on Mesa or lump with other stuff yet.
It looks like there were intermittent problems with this test recently. We should look at them.
I have built ToT link today and switching to developer console works fine. I will run the test as well. Maybe it is a problem with uinput?

Comment 6 by dbehr@chromium.org, Nov 7 2017

Owner: dbehr@chromium.org
Status: Started (was: Duplicate)

Comment 7 by dbehr@chromium.org, Nov 7 2017

Yeah, graphics_VTSwitch sometimes tries to screenshot new instance of Chrome it starts before it fully started. New Mesa seems to have made it little slower so it happens more often.
Project Member

Comment 8 by bugdroid1@chromium.org, Nov 9 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/ac659e33a44d2d8204a0d68081eb2d79ccf76958

commit ac659e33a44d2d8204a0d68081eb2d79ccf76958
Author: Dominik Behr <dbehr@chromium.org>
Date: Thu Nov 09 03:48:53 2017

graphics_VTSwitch: add delay between starting Chrome and screenshot

Add 10 second delay before screenshot is taken. It may take a while for Chrome
to start and switch video mode and show something on screen. Taking screenshot
immediately sometimes can capture just empty black screen.

BUG= chromium:781884 
TEST=run 50 iterations of graphics_VTSwitch on Link

Change-Id: I5b3cdc81f3d95b48220c03817a7ae52c356c94a1
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/757782
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>

[modify] https://crrev.com/ac659e33a44d2d8204a0d68081eb2d79ccf76958/client/site_tests/graphics_VTSwitch/graphics_VTSwitch.py

Comment 9 by dbehr@chromium.org, Nov 13 2017

Status: Fixed (was: Started)

Sign in to add a comment