Item 3: fold the debug kernel into the closing build

kas/forgefirm-glowforge-debug.yml builds one dev image on the debug
kernel (FORGEFIRM_KERNEL_DEBUG=1, tagged dev-debug) beside the closing
release and dev images; the debug options never touch either.
scripts/bench/debug_kernel_drills.py runs the two drills (three
load/unload cycles under DEBUG_MUTEXES, a forced -EPROBE_DEFER unwind),
each read against dmesg for lock splats, refusing on a non-debug kernel
or a non-idle machine; it is registered as a board bench tool. BRINGUP
item 3 names the mechanism and stays remaining work (run it on the
closing burn); the site's Build page documents the variant.
This commit is contained in:
ScottW514
2026-08-31 15:54:28 -04:00
parent 8ba998c3ef
commit 298abf8a12
4 changed files with 230 additions and 7 deletions
+7 -7
View File
@@ -1115,13 +1115,13 @@ Open items only. Anything closed is in `CAMPAIGN-LOG.md`.
reachable-mode reasoning and the factory fallback configuration are in
the headers of kernel patches 0011-0013 (`meta-glowforge-bsp`,
`recipes-kernel/linux/`).
3. **Debug-kernel checks.** Module load/unload under `CONFIG_DEBUG_MUTEXES`
and a forced `-EPROBE_DEFER` unwind still need a debug kernel build. Both
drills cycle what the rail policy avoids: a module unload powers the 40 V
rail off (a stepper driver can come out of the power-up unserviceable),
and a forced defer needs the 40 V regulator or the SDMA device unbound
under the module's probe. This is a bench slot with the rail-cycle gamble
accepted, not a quick check.
3. **Debug-kernel checks.** Run the module load/unload and forced
`-EPROBE_DEFER` drills (`scripts/bench/debug_kernel_drills.py`) on the
debug-kernel image (`kas/forgefirm-glowforge-debug.yml`, built beside the
closing image). Both cycle the 40 V rail: a module unload powers it off (a
stepper driver can come out of the power-up unserviceable), and the forced
defer needs the 40 V regulator unbound under the probe. It is a bench slot
with the rail-cycle gamble accepted, and it rides the closing burn.
4. **Release acceptance follow-through.** The campaign is the release gate
and runs as designed: dev image `20260824230512`, 45 of 45 from nothing,
36 of them unattended with the bench actuator in the loop, release