Report a failed CPU or GPU stress test instead of always passing

[munzzyy]

The CPU and GPU stress tests report a pass in the board report even when the stress process dies on startup and no load is ever applied.

Two things combine to cause it.

generate_combined_report.py checks the marker file like this:

if 'CPU_STRESS=RUNNING' in marker_content or 'PID=' in marker_content:
    cpu_stress_status = 'success'  # Assume success if marker exists
elif 'STATUS=FAILED' in marker_content:
    cpu_stress_status = 'failed'

cpu_test.sh writes CPU_STRESS=RUNNING at line 21 and PID= at line 38, both unconditionally, so the first branch always matches and the STATUS=FAILED branch can't be reached. Nothing writes STATUS=FAILED in the first place, so even reordering alone wouldn't change anything. gpu_test.sh and the GPU half of the report have the same shape.

So I did both halves: check STATUS=FAILED first, and actually write it when the stress process isn't alive a second after launch. For the GPU that means checking all four PIDs and only marking failed if none survived.

Reproduced with a stress-ng stub that exits 1 immediately, running the real cpu_test.sh:

CPU_STRESS=RUNNING
START_TIME=2026-07-27 13:50:24
DURATION=INFINITE
PID=72318
STATUS=FAILED      <- new

Same marker file through both versions of the check:

fixed logic  -> failed
old logic    -> success

The one-second sleep is there because the PID exists for a moment either way, so kill -0 right after $! would pass even for a process that's already on its way out. It only delays the two stress scripts by a second each.

Worth saying: I could only test this on a normal x86 Linux box with stubbed binaries, not on an RK3576 board, so a look from someone with hardware would be good — particularly on whether one second is enough headroom for glmark2 to get going on that GPU.

One thing worth heading off: the kill -0 check would be wrong if a stress run could legitimately finish inside that second. It can't here — stress-ng --cpu 0 --metrics-brief is started with no --timeout, and all four glmark2 processes use --run-forever. Both are meant to run until start-tests.sh kills them, so a process that's gone after a second has died, not finished.