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

Issue 842352 link

Starred by 3 users

Issue metadata

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

Blocked on:
issue 819882



Sign in to add a comment

tricky cannot enter recovery

Project Member Reported by haoweiw@chromium.org, May 11 2018

Issue description

My plan is testing all MP/PVT devices to see if we can start moving them to Prometheus lab. 
Blockedon: 819882
Components: -Infra>Client>ChromeOS Infra>Client>ChromeOS>Test
Owner: haoweiw@chromium.org
Status: Assigned (was: Untriaged)
Doesn't look like this bug needs triage
Owner: nsanders@chromium.org
> Doesn't look like this bug needs triage

Based on comment #1 and comment #2, this is a servo-V4 specific
problem.

nsanders@ can suggest triage steps/ownership.

We need to log what the failure actually is before triage is possible.
I have the error message detailed in the testing logs. 

power_state:rec did not turn DUT on.

Visually, the DUT stays off once tried to invoke power_state:rec.


I've seen a guado get wedged in recovery (turned on) but with the screen off, if USB is hung. I wonder if tricky could have the same problem?

On my guado, placing a passive USB hub between the servo v4 and the DUT seems to have improved USB access in recovery. May be worth trying with a tricky to see if that helps the problem?
Using passive USB hub but no help.

I even tried plug USB direct to DUT but still not booting. Only black screen. 
Issue observed, device is not able to boot into USB recovery image if HDMI display is not plugged in.
Summary: tricky cannot enter recovery (was: tricky failed on Servo V4 Testing. )
Update title to reflect that recovery doesn't work with or without servo v4.
> Update title to reflect that recovery doesn't work with or without servo v4.

... But that statement isn't quite true:  In comment #1 we have a
unit that clearly passed the test.  That wouldn't happen if recovery
mode categorically doesn't work.

Also, this comment:

> Issue observed, device is not able to boot into USB recovery image if HDMI display is not plugged in.

This statement also belies the fact that a unit in the lab _did_
pass the test.  AFAIK, only chameleon hosts would have an HDMI
display, and the unit that passed didn't have a chameleon attached.

The test failed from comment #1
FAIL	platform_ServoPowerStateController	platform_ServoPowerStateController	timestamp=1526076515	localtime=May 11 15:08:35	power_state:rec did not turn DUT on.


> The test failed from comment #1

We seem to be looking at different test results.  I'm talking about this
job:
    https://ubercautotest.corp.google.com/afe/#tab_id=view_job&object_id=200065779

Here's the complete status.log:
START	platform_ServoPowerStateController	platform_ServoPowerStateController	timestamp=1526315360	localtime=May 14 09:29:20	
	START	----	----	timestamp=1526315380	localtime=May 14 09:29:40	
		GOOD	----	sysinfo.before	timestamp=1526315380	localtime=May 14 09:29:40	
	END GOOD	----	----	timestamp=1526315380	localtime=May 14 09:29:40	
	START	----	----	timestamp=1526315392	localtime=May 14 09:29:52	
		GOOD	----	sysinfo.iteration.before	timestamp=1526315392	localtime=May 14 09:29:52	
	END GOOD	----	----	timestamp=1526315392	localtime=May 14 09:29:52	
	START	----	----	timestamp=1526315941	localtime=May 14 09:39:01	
		GOOD	----	sysinfo.iteration.after	timestamp=1526315941	localtime=May 14 09:39:01	
	END GOOD	----	----	timestamp=1526315941	localtime=May 14 09:39:01	
	START	----	----	timestamp=1526316004	localtime=May 14 09:40:04	
		GOOD	----	sysinfo.after	timestamp=1526316004	localtime=May 14 09:40:04	
	END GOOD	----	----	timestamp=1526316004	localtime=May 14 09:40:04	
	GOOD	platform_ServoPowerStateController	platform_ServoPowerStateController	timestamp=1526316013	localtime=May 14 09:40:13	completed successfully
END GOOD	platform_ServoPowerStateController	platform_ServoPowerStateController	timestamp=1526316013	localtime=May 14 09:40:13	

Well, I think the problem here is to deal with Servo V4. 
It's not clear that we have any kind of systemic problem.  See here:
    http://shortn/_6xprR0r3rU

We've added platform_ServoPowerStateController to bvt-perbuild, so now
it runs regularly on randomly selected tricky hardware.  Thus far, the
test has yet to fail on tricky, meaning there's at least one DUT in the
BVT pool consistently passing the test.

Cc: englab-sys-cros@google.com johndhong@chromium.org
Is there a way to tell which device is passing that test? 
> Is there a way to tell which device is passing that test? 

It'll be available in the test logs.  Click on the green box, and then
follow your nose.

Sign in to add a comment