> dut-control kbd_en:off kbd_m2_a1:0 kbd_m2_a0:0 kbd_m1_a1:0 kbd_m1_a0:1 kbd_en:on sleep:0.5 kbd_en:off

I'm uncertain how fully supported that command is.  In particular,
if it works for some boards or some versions of servo, but not others,
it may or may not qualify as a bug worth fixing.

There's a platform independent 'dut-control' command that's required
to work:
    dut-control power_state:off power_state:rec

If that command doesn't reliably force a device into recovery mode
regardless of board or servo version, it's a high priority bug.

Generally, you should use the wrapper to send ctrl-d or whatever rather
than poking the underlying keyboard rails.

However servo micro should support this. Can you check if only this
function is failing or the servo micro is completely unresponsive?

power_state is not a valid argument to Servo V4.

localhost ~ # dut-control warm_reset
warm_reset:off
localhost ~ # dut-control warm_reset:on                                        
<bd_en:off kbd_m2_a1:0 kbd_m2_a0:0 kbd_m1_a1:0 kbd_m                            <m2_a0:0 kbd_m1_a1:0 kbd_m1_a0:1 kbd_en:on sleep:0.5 kbd_en:off              
Problem with ['kbd_en:off', 'kbd_m2_a1:0', 'kbd_m2_a0:0', 'kbd_m1_a1:0', 'kbd_m1_a0:1', 'kbd_en:on', 'sleep:0.5', 'kbd_en:off'] :: No control named "kbd_en"

<_m1_a1:0 kbd_m1_a0:1 kbd_en:on sleep:0.5 kbd_en:off                           
Problem with ['kbd_en:off', 'kbd_m2_a1:0', 'kbd_m2_a0:0', 'kbd_m1_a1:0', 'kbd_m1_a0:1', 'kbd_en:on', 'sleep:0.5', 'kbd_en:off'] :: No control named "kbd_en"

localhost ~ # dut-control warm_reset:off5 kbd_en:off                           
localhost ~ # dut-control warm_reset                                           
warm_reset:off
localhost ~ # dut-control warm_reset:on                                        
<_m1_a1:0 kbd_m1_a0:1 kbd_en:on sleep:0.5 kbd_en:off                            localhost ~ # dut-control warm_reset:off5 kbd_en:off  

> power_state is not a valid argument to Servo V4.

If that statement were true as a general matter, the deployment
script would fail.  (So I don't believe that this is generally
true.)  Can you provide more information about what error you saw,
specifically?

Here is the original error of cave deployment. 

gs://chromeos-install-logs/2017-01-23T10:37:45.660407-08:00-cave/chromeos2-row1-rack11-host1.log
gsutil cat gs://chromeos-install-logs/2017-01-23T10:37:45.660407-08:00-cave/report.log

@ nsanders@chromium.org - does this give you what you need to triage?

power_state is absolutely supported on servo v4/micro and is the only way this functionality is supported on servo v4. It's not expected that keyboard bitbanging will work under CCD.

Can you attach the result of 
dut-control power_state:off power_state:rec

From your cut and paste it looks like some other task is calling dut-control and stomping on things while you are running? I'm not sure what's going on.

Unfortunately I don't have any system to repro this, possibly kevin can take a look.

How did you start servod? The power_state control is usually defined in the CrOS board overlay, like servo_glados_overlay.xml. Should start servod like "servod -b glados" argument. Starting it like "servod -c servo_v4.xml" will loss the power_state control.

I am a bit confused. So it failed to boot into recovery screen, or failed to press Ctrl-D to switch to dev mode?

If it failed to press Ctrl-D, better to check the EC log to see if the keys are sent or not.

Bulk-edit, reassigning to Aviv to assign to someone.

Gathered onto a servo v4 hotlist, removing self as owner.