For the record, these are the DUTs in the failed tests:
    chromeos4-row10-rack2-host4
    chromeos4-row10-rack2-host6
    chromeos4-row10-rack2-host7

Information on the servos as of now:
chromeos4-row10-rack2-host4 ...ABCDEFG is up BOARD=fizz CHROMEOS_RELEASE_VERSION=10052.0.0
chromeos4-row10-rack2-host6 ...ABCDEFG is up BOARD=fizz CHROMEOS_RELEASE_VERSION=10178.0.0
chromeos4-row10-rack2-host7 ...ABCDEFG is up BOARD=fizz CHROMEOS_RELEASE_VERSION=10052.0.0

Is this specific to teemo or generally across fizz?

> Is this specific to teemo or generally across fizz?

Unknown:  The only DUTs available for testing in the lab are teemo.

It's worth mentioning that the teemo devices in the lab seem to be
all servo-V3 based.

I'll give it a shot with servo micro and presumably it will have the same error. 

I'm not going to be able to start on this until after Dru deployment works, so if this is urgent someone more familiar with Servo v3 should pick it up

This fix will involve the same code as  bug 834063 ; most likely
both should be handled at the same time.

power_state:rec is working on my fizz/teemo device.

Also, it's passing faft tests, which require power_state:rec to work.

Can I get more details on the setup?  The FW Qual team uses servo micro for running faft tests and I'm using servo V2 and we haven't seen this problem.

For teemo in the lab, we're using servo V3.  I'm re-running the
servo test now:
    https://ubercautotest.corp.google.com/afe/#tab_id=view_job&object_id=194995039

I've run the test twice now, on two different hosts:
    https://ubercautotest.corp.google.com/afe/#tab_id=view_job&object_id=194995039
    https://ubercautotest.corp.google.com/afe/#tab_id=view_job&object_id=194995088

In both cases, we now get a different failure message:
    power_state:on did not turn DUT on.

Checking history after the test, it does appear that the DUTs were offline
immediately after the test.  So, this sequence seems not to work:
    power_state:off power_state:on

Both of the DUTs are now online, and at least one of them successfully
reinstalled from USB (results are pending on the second).  That means that
power_state:rec worked, at least in the one case.  The repair log also shows
that (as expected) power_state:reset doesn't work.

One more point of note:  Servos for both DUTs are running the current lab
standard version, R68-10599.0.0.

I believe shchen@ is working on this in buganizer. Maybe fixed already?

I haven't been working on this.  I fixed the power_state:reset issue for fizz (https://bugs.chromium.org/p/chromium/issues/detail?id=834063)  and verified that power_state:off and power_state:on are working through servo v2 (at my desk) and servo micro (fw qual team).

I think that it's either an issue with servo v3 or a lab issue.

We've recently upgraded Servo in the lab to R68-10635.0.0.  That
contains the fix for power_state:reset.  There are anecdotes suggesting
that power_state:rec may be better in that version as well.

I've started a test job to see how the servo test fares against the latest
servo version:
    https://ubercautotest.corp.google.com/afe/#tab_id=view_job&object_id=196751010

>     https://ubercautotest.corp.google.com/afe/#tab_id=view_job&object_id=196751010

This test run passed.  That suggests that there have been servo
changes since 10178.0.0 that fixed the problem.  From comments #13
and #14, it looks like the fix could have been as early as
R68-10599.0.0.  That's roughly the time of the big servo change from
nsanders@.

Probably, with all the recent changes, teemo (and I presume, fizz) is
now working.  Just to be sure, I've started this additional test run:
    https://ubercautotest.corp.google.com/afe/#tab_id=view_job&object_id=196752182

The second test passed as well.  It seems like this isn't a fluke,
and we can call this fixed.