Power After Fail suite shuts down platform for good (until reflashed) #930
Description
Device
V1000 JSL platforms
RTE version
OSFV version
Affected component(s) or functionality
PSF002.001 of power-after-fail suite:https://github.com/Dasharo/open-source-firmware-validation/blob/develop/dasharo-compatibility/power-after-fail.robot
(after separate test runs it turns out PSF004.002 triggers the same effect and also needs some attention)
Brief summary
Power After Fail suite changes power state after failure options and tests lose control over the power state of the platform and all consecutive tests fail due to the platform being powered off
How reproducible
100%
How to reproduce
run
RTE_IP=192.168.10.198 FW_FILE=v1410 CONFIG=protectli-v1410 DEVICE_IP=192.168.10.154 ./scripts/run.sh dasharo-compatibility/power-after-fail.robot
(for example on v1410)
Expected behavior
þąśś
Actual behavior
tests chronologically after PSF002.001 FAIL (other test suites included!!):
MNE003.201 Intel ME mode option Disabled (Soft) works correctly (U... | FAIL |
Parent suite setup failed:
Power LED didn't light up! Setup needs manual verification,
Explanation: This occurs in the Power On keyword, which is unable to turn the platform on because it reads from ${DEFAULT_POWER_STATE_AFTER_FAIL} that the state is Powered On, which is incorrect, because we recently changed the UEFI option to Powered Off within the test.
Think of it like the ${DUT_CONNECTION_METHOD} (1) and ${INITIAL_DUT_CONNECTION_METHOD} (2) keywords. We use both a regular and a default version: we operate on the regular one (1) during the test, and once the test is complete, we restore the original state using the initial (2) DUT connection method to reassign the regular one (1).
One solution to this could be introducing a temporary state variable and a reset keyword for ${DEFAULT_POWER_STATE_AFTER_FAIL}.
We could also implement a reset to defaults (or something similar) to restore the UEFI settings after a suite is completed, ensuring that future tests start from a clean state .
Example form the logs:
Fig. 1 – The robot attempts to retrieve ${DEFAULT_POWER_STATE_AFTER_FAIL}. However, due to a change introduced by a prior test, the value no longer reflects the intended default — leading to unexpected behavior during the current power state validation.
NOTE: To restore platform to the original state, flashing the BIOS or connecting via serial and changing the option manually both proved to be an effective method.
NOTE: Running the PSF tests separately helped me narrow the suspect list to PSF002.001 and PSF004.002 other PSF tests didn't disrupt the flow of tests that follow.
Link to screenshots or logs
Additional context
No response
Solutions you've tried
No response