ef93a4fa14
Source changes (dormant parity infra, retained from iterate 2.AI/2.AO): - xenia-kernel/exports.rs: nt_create_event manual_reset polarity + related event wiring - xenia-gpu/mmio_region.rs: D1MODE_VBLANK_VLINE_STATUS hardcode parity Also lands the audit-runs/ analysis notes (.md/.txt/.json digests) for the iterate 2.x VSync/0x10e8/0x1004 wedge investigation. Raw trace dumps (.jsonl/.gz/.csv/.stdout) and agent worktrees (.claude/) are gitignored as regenerable local artifacts — see memory + HANDOFF for the running findings. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.4 KiB
Progression-metric result — Review A Step 1
Date: 2026-05-27
PRIMARY gate: swaps > 1 OR draws > 0 OR unique_render_targets > 0.
Composite progression score (per Review A Q5)
score = 1*swaps + 10*draws + 100*unique_render_targets
| Run | swaps | draws | unique_RT | score |
|---|---|---|---|---|
| OFF-1 | 1 | 0 | 0 | 1 |
| OFF-2 | 1 | 0 | 0 | 1 |
| OFF-3 | 1 | 0 | 0 | 1 |
| ON-1 | 1 | 0 | 0 | 1 |
| ON-2 | 1 | 0 | 0 | 1 |
| ON-3 | 1 | 0 | 0 | 1 |
- OFF mean: 1.0
- ON mean: 1.0
- Δ (ON - OFF): 0
PRIMARY gate verdict
FAIL. No swap beyond the boot-init swap; no draws; no render
targets. The crowbar fires successfully (4/4 workers spawned and
resumed) but the workers fault ~159 instructions in on the unmapped
canary VA 0xBCE25640, before they can advance the wedge or emit
PM4 draw commands.
What "winning" would have required
Per shortest-path-roadmap.md §"What 'winning' looks like":
{
"draws": >= 1,
"swaps": >= 2,
"unique_render_targets": >= 1
}
reproducible across 3 cold runs. Observed: all 0/1/0 across 6 runs (3 OFF + 3 ON). Matches v3's 2026-05-21 outcome bit-for-bit at the progression-metric level (Δ = 0).
Why the crowbar didn't unblock
Per v3 investigation.md §"The fault (v3)" and re-validated this
session: the worker entry stubs at 0x82506528/58/88/B8 dispatch
through vtable[35..38] to fns like sub_82506E08, sub_82508520,
etc. Those fns immediately load [ctx+44] into r3 expecting a
secondary-object pointer (per canary's runtime ctx state). In v3 the
secondary-object pointer was captured as 0xBCE25640 and installed
verbatim per Option γ. In ours's address space, 0xBCE25640 is
not allocated (ours's allocator namespace is 0x4000_0000..0x6FFF_FFFF).
Reading [0xBCE25640] returns 0 → CTR=0 → bctrl faults at PC=0.
The fault is bit-stable across 3× cold ON runs (deterministic
scheduling under --gpu-thread).
Matched-prefix shift under crowbar (informational only — NOT a gate)
Matched-prefix vs canary was NOT computed in this session because the crowbar fundamentally alters guest control flow (introduces 4 host-spawned threads with synthesised ctx state). Per reading-error #23, matched-prefix regression under crowbar-on is EXPECTED and not a failure indicator — the PRIMARY gate is progression metric, not matched-prefix.