[Fix] (Trace, Bench, CI): compute p50 by the device's own median rule, fail the profile guard closed, and give the new control step its sibling's environment

- format_benchmark printed a p50 taken with the nearest-rank rule beside a medianFrameCpuMs the
  device computes as the average of the two middle frames, and documented the two as one rule; on
  an even window they differ (the pre-flight printed p50=8.261ms next to medianCpuMs=271.766).
  p50 now goes through series_median, which is SummarizeSeries' rule transcribed; p95 and p99 stay
  nearest rank, which is the device's rule for p95 and the honest extension of it for the p99 the
  device does not compute at all
- require_verified_profile treated a profile that simply omits PROFILE_VERIFIED as verified, which
  is the fail-open default a profile written by copying another one inherits - exactly the case the
  guard exists for. It defaults to unverified now, odinlite.env carries PROFILE_VERIFIED=1
  explicitly (it is the one profile that earned it), and the refusal says "says 0, or says nothing"
- the two new profiles claimed profile.sh refuses an unverified profile; it has no such check and
  needs none - it records a simpleperf profile and pins nothing. The claim is corrected in both
  profiles and in the README rather than a guard added where there is nothing to guard
- the handle-ABA / CSO control step in test.yml set only MOBILEGL_ITEST_REQUIRE_GPU while its
  sibling verify step sets the three MOBILEGL_MAGMA_* fixes and arms core dumps. It runs the same
  DirectVulkan binary on the same runner, so a crash there left no core; it now carries both
This commit is contained in:
2026-09-07 23:18:09 -04:00
parent a5d1136c02
commit af20dba6db
8 changed files with 73 additions and 20 deletions
+3
View File
@@ -35,6 +35,9 @@ frequency-pin integrity.
(`big_cur`/`little_cur`/`gpu_cur_khz` in the result JSON must match the pins). Until then
it says `PROFILE_VERIFIED=0` and `bench.sh` / `session.sh` refuse to run against it unless
`--allow-unverified-profile` is passed, which labels the run unpinned in the warning.
**A profile that omits the key entirely is refused the same way** - the guard defaults to
unverified, so copying a verified profile and editing the serial cannot inherit its verdict.
(`profile.sh` pins nothing - it records a simpleperf profile - so it carries no such guard.)
That refusal exists because the pin path is silent when it is wrong: the harness writes
through `/proc/ppm/policy/hard_userlimit_*` and `/proc/gpufreq/gpufreq_opp_freq`, which are