Confirmed users
120
edits
ReleaseEngineering/Mozpool/Handling Panda Failures: Difference between revisions
ReleaseEngineering/Mozpool/Handling Panda Failures (view source)
Revision as of 17:05, 11 February 2013
, 11 February 2013→Known Issues and Handling
| Line 84: | Line 84: | ||
There are a couple of known issues that require manual intervention. | There are a couple of known issues that require manual intervention. | ||
# sut_verify | # sut_verify: There is a known bug bug 836417 causing all sut_verifying checks to fail after a reimage. The workaround for this is to force state "sut_verifying" a few minutes after the first failure. | ||
# failed_b2g_pinging: At this time mozpool cannot detect whether this state was caused by a bad panda or a bad b2g build or just a failed hardware (probably ethernet) initialization. For handling this state, find the failed panda in the lifeguard UI and execute a "please_self_test". This should test the board and put it back into a free state. If the board continues to be a repeat offender and ending up in a failed_b2g_pinging state, follow the [[#Log Failure In Interim Tracking Bug]] instructions and log under the Interim Bad Panda bug. | # failed_b2g_pinging: At this time mozpool cannot detect whether this state was caused by a bad panda or a bad b2g build or just a failed hardware (probably ethernet) initialization. For handling this state, find the failed panda in the lifeguard UI and execute a "please_self_test". This should test the board and put it back into a free state. If the board continues to be a repeat offender and ending up in a failed_b2g_pinging state, follow the [[#Log Failure In Interim Tracking Bug]] instructions and log under the Interim Bad Panda bug. | ||