Make the BattOr agent retry start tracing when we fail to read an ack

Make the BattOr agent retry start tracing when we fail to read an ack

This should greatly mitigate a current bug in the BattOr firmware where
sending the command to start tracing causes the BattOr to reset. In this
case, we now retry the full initialization sequence. Because the error
we're hitting is a timeout, and we allow 4 seconds for a command to
be executed before timing out, this means that initialization will
retry after 4 seconds and then make 20 attempts to initialize the BattOr
100 milliseconds apart from each other, making the whole sequence take
something like 6 additional seconds. We can retry this full sequence
up to 5 times. When added to the five or so seconds that the BattOr
already takes to initialize, this means that this full sequence might
take up to 11 * 5 = 55 seconds before deciding that the BattOr can't
be initialized. In practice, I suspect that almost all initializations
will succeed on either their first or second attempts.

BUG=672631
Committed: https://crrev.com/ee8618f9e765917145cc20b136cb6a3ba324db53
Cr-Commit-Position: refs/heads/master@{#437548}

[charliea (OOO until 10-5), 2016-12-09 14:34:34]

Description was changed from

==========
Make the BattOr agent retry start tracing when we fail to read an ack

This should greatly mitigate a current bug in the BattOr firmware where
sending the command to start tracing causes the BattOr to reset. In this
case, we now retry the full initialization sequence. Because the error
we're hitting is a timeout, and we allow 4 seconds for a command to
be executed before timing out, this means that initialization will
retry after 4 seconds and then make 20 attempts to initialize the BattOr
100 milliseconds apart from each other, making the whole sequence take
something like 6 additional seconds. We can retry this full sequence
up to 5 times. When added to the five or so seconds that the BattOr
already takes to initialize, this means that this full sequence might
take up to 11 * 5 = 55 seconds before deciding that the BattOr can't
be initialized. In practice, I suspect that almost all initializations
will succeed on either their first or second attempts.

BUG=672631
==========

to

==========
Make the BattOr agent retry start tracing when we fail to read an ack

This should greatly mitigate a current bug in the BattOr firmware where
sending the command to start tracing causes the BattOr to reset. In this
case, we now retry the full initialization sequence. Because the error
we're hitting is a timeout, and we allow 4 seconds for a command to
be executed before timing out, this means that initialization will
retry after 4 seconds and then make 20 attempts to initialize the BattOr
100 milliseconds apart from each other, making the whole sequence take
something like 6 additional seconds. We can retry this full sequence
up to 5 times. When added to the five or so seconds that the BattOr
already takes to initialize, this means that this full sequence might
take up to 11 * 5 = 55 seconds before deciding that the BattOr can't
be initialized. In practice, I suspect that almost all initializations
will succeed on either their first or second attempts.

BUG=672631
==========

[charliea (OOO until 10-5), 2016-12-09 14:34:34]

charliea@chromium.org changed reviewers:
+ rnephew@chromium.org

[charliea (OOO until 10-5), 2016-12-09 14:35:14]

The CQ bit was checked by charliea@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-09 14:35:34]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[rnephew (Reviews Here), 2016-12-09 14:46:48]

On 2016/12/09 14:35:34, commit-bot: I haz the power wrote:
> Dry run: CQ is trying da patch. Follow status at
>  
>
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

lgtm

[charliea (OOO until 10-5), 2016-12-09 14:48:47]

The CQ bit was unchecked by charliea@chromium.org

[charliea (OOO until 10-5), 2016-12-09 14:48:48]

The CQ bit was checked by charliea@chromium.org

[commit-bot: I haz the power, 2016-12-09 14:48:58]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-09 15:44:00]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1481294928255860, "parent_rev":
"334b83ccbe36016e25e85896a5acc3f6c95af140", "commit_rev":
"6cf7a9128f47e1d8c8df67fb76c26c2b2c086d30"}

[commit-bot: I haz the power, 2016-12-09 15:48:33]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1481294928255860, "parent_rev":
"6e4a631204496d4d3ded9a6469da6a6b1da7e58f", "commit_rev":
"8a13694642d7bbf97a225ab256c9de0ffb4f5073"}

[commit-bot: I haz the power, 2016-12-09 15:49:19]

Description was changed from

==========
Make the BattOr agent retry start tracing when we fail to read an ack

This should greatly mitigate a current bug in the BattOr firmware where
sending the command to start tracing causes the BattOr to reset. In this
case, we now retry the full initialization sequence. Because the error
we're hitting is a timeout, and we allow 4 seconds for a command to
be executed before timing out, this means that initialization will
retry after 4 seconds and then make 20 attempts to initialize the BattOr
100 milliseconds apart from each other, making the whole sequence take
something like 6 additional seconds. We can retry this full sequence
up to 5 times. When added to the five or so seconds that the BattOr
already takes to initialize, this means that this full sequence might
take up to 11 * 5 = 55 seconds before deciding that the BattOr can't
be initialized. In practice, I suspect that almost all initializations
will succeed on either their first or second attempts.

BUG=672631
==========

to

==========
Make the BattOr agent retry start tracing when we fail to read an ack

This should greatly mitigate a current bug in the BattOr firmware where
sending the command to start tracing causes the BattOr to reset. In this
case, we now retry the full initialization sequence. Because the error
we're hitting is a timeout, and we allow 4 seconds for a command to
be executed before timing out, this means that initialization will
retry after 4 seconds and then make 20 attempts to initialize the BattOr
100 milliseconds apart from each other, making the whole sequence take
something like 6 additional seconds. We can retry this full sequence
up to 5 times. When added to the five or so seconds that the BattOr
already takes to initialize, this means that this full sequence might
take up to 11 * 5 = 55 seconds before deciding that the BattOr can't
be initialized. In practice, I suspect that almost all initializations
will succeed on either their first or second attempts.

BUG=672631

Review-Url: https://codereview.chromium.org/2563033002
==========

[commit-bot: I haz the power, 2016-12-09 15:49:20]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-12-09 15:51:13]

Description was changed from

==========
Make the BattOr agent retry start tracing when we fail to read an ack

This should greatly mitigate a current bug in the BattOr firmware where
sending the command to start tracing causes the BattOr to reset. In this
case, we now retry the full initialization sequence. Because the error
we're hitting is a timeout, and we allow 4 seconds for a command to
be executed before timing out, this means that initialization will
retry after 4 seconds and then make 20 attempts to initialize the BattOr
100 milliseconds apart from each other, making the whole sequence take
something like 6 additional seconds. We can retry this full sequence
up to 5 times. When added to the five or so seconds that the BattOr
already takes to initialize, this means that this full sequence might
take up to 11 * 5 = 55 seconds before deciding that the BattOr can't
be initialized. In practice, I suspect that almost all initializations
will succeed on either their first or second attempts.

BUG=672631

Review-Url: https://codereview.chromium.org/2563033002
==========

to

==========
Make the BattOr agent retry start tracing when we fail to read an ack

This should greatly mitigate a current bug in the BattOr firmware where
sending the command to start tracing causes the BattOr to reset. In this
case, we now retry the full initialization sequence. Because the error
we're hitting is a timeout, and we allow 4 seconds for a command to
be executed before timing out, this means that initialization will
retry after 4 seconds and then make 20 attempts to initialize the BattOr
100 milliseconds apart from each other, making the whole sequence take
something like 6 additional seconds. We can retry this full sequence
up to 5 times. When added to the five or so seconds that the BattOr
already takes to initialize, this means that this full sequence might
take up to 11 * 5 = 55 seconds before deciding that the BattOr can't
be initialized. In practice, I suspect that almost all initializations
will succeed on either their first or second attempts.

BUG=672631

Committed: https://crrev.com/ee8618f9e765917145cc20b136cb6a3ba324db53
Cr-Commit-Position: refs/heads/master@{#437548}
==========

[commit-bot: I haz the power, 2016-12-09 15:51:13]

Patchset 1 (id:??) landed as
https://crrev.com/ee8618f9e765917145cc20b136cb6a3ba324db53
Cr-Commit-Position: refs/heads/master@{#437548}