fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

backlog: mark the freeze entry's "first step" done, and rule out --log_mask=0

Browse Source 
Two updates to the mission-freeze entry, both measured.

DONE: the entry's "first step, revised" was "make pilot.py shoot, then re-run
ob_flag.py ... the actual obstacle is that nothing the pilot does moves the
counter".  pilot.py now has SYLPH_WEAKEST=1 (target score scaled by remaining
hull) and the next run moved REMAINING OB 008 -> 007 concurrent with the live e010
floor dropping 16 -> 15.  The counter is fully solved; the freeze work now needs
only a frozen sample for the v2 wait probe.

DEAD END, with numbers: --log_mask=0 does not surface kernel call traces.  A full
Stage 02 run produced 199 MB at ~33 MB/min, and a 300k-line tail is 254127 A>
(Apu/XMA), 42444 d>, 2897 G>, 532 w>, with ZERO k> and only 14 K> lines per 58k of
boot.  XamShowSigninUI / KeWaitForSingleObject / NtWaitForSingleObject each appear
exactly once in the whole log -- an export listing, not call traces.  That
independently confirms the entry's own cost note: those calls are kHighFrequency
and silent without --log_high_frequency_kernel_calls=true.

The run also did not freeze (healthy TIME 00:24.28 -> 03:33.28), making it the
fourth consecutive non-freezing run.
This commit is contained in:
Sylpheed RE agent
2026-08-27 04:43:18 +00:00
parent d1640548f9
commit a8e387b564
1 changed files with 26 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
docs/re/BACKLOG.md
View File

@@ -1788,6 +1788,32 @@ is what the autopilot needs in order to CHOOSE a target. One run in:
`ob_flag.py` abort on it. **Roughly two runs in three.**
See [`mission-freeze-resume-spin.md`](mission-freeze-resume-spin.md).
> ### ✅ 2026-08-27 — the "first step, revised" below is DONE, and `--log_mask=0` is a dead end
>
> **The counter moves.** `pilot.py` gained `SYLPH_WEAKEST=1` (score scaled by the
> target's remaining hull, so fire concentrates on one already-damaged craft
> instead of spreading over a squadron) and the very next run drove
> `REMAINING OB` **008 → 007**, concurrent with the live `e010` floor dropping
> 16 → 15. `REMAINING OB` is now fully solved — see
> [`ob-counts-marked-attackers.md`](ob-counts-marked-attackers.md). So the
> obstacle this entry names is cleared; what the freeze work still needs is only
> a **frozen sample** for the v2 probe to compare against.
>
> ❌ **Do not try `--log_mask=0` for that sample.** Measured on a full Stage 02
> run: **199 MB of log**, growing **~33 MB/min**, and a 300 k-line tail is
> **254 127 `A>` (Apu/XMA)**, 42 444 `d>`, 2 897 `G>`, 532 `w>` — with **zero**
> `k>` and only **14 `K>` lines in a 58 k-line boot sample**. `XamShowSigninUI`,
> `KeWaitForSingleObject` and `NtWaitForSingleObject` each appear exactly **once**
> in the whole 199 MB, i.e. in an export listing, never as call traces. That
> independently confirms the cost note above: kernel calls are `kHighFrequency`
> and stay silent without `--log_high_frequency_kernel_calls=true`, so `log_mask=0`
> buys nothing but audio spam. The purpose-built `--log_stuck_waits` probe remains
> the right instrument.
>
> ⚠️ That run also **did not freeze** — healthy from `TIME 00:24.28` to
> `03:33.28`, `frozen.py` animating throughout — making it the fourth
> consecutive non-freezing run across this entry and the last session.
**First step, revised:** make `pilot.py` shoot, then re-run `ob_flag.py`. The
freeze is no longer the blocker it looked like — a 25-minute run stayed
animating — and the actual obstacle is that nothing the pilot does moves the