51940f49d0687f510a90f30e5146977df72057d6
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Robert Allan JamesandClaude Sonnet 5
|
51940f49d0 |
Add per-slot CRC + campaign crash-resume (DOE-RESUME-COUNT)
FABRIC-3.md §XXXV.12: closes two real gaps found by walking the disk-to- PDF pipeline end to end. (1) doe_trial_slot_t had no integrity check of its own -- 64 slots share one devblock via a read-modify-write, so a crash mid-write to any slot could silently corrupt its siblings with nothing to catch it. Added an 8-byte CRC (same discipline the control header already had), computed/verified the same way. (2) The campaign itself had no crash-resume -- a reboot always restarted the whole 18-trial loop from index 0 even with good persisted data already on disk. Since the trial matrix is fully deterministic from (seed, n-reps), resuming needs no persisted "which trials ran" state, just a count: DOE-RESUME-COUNT (new kernel primitive, same pattern as DOE-PERSIST-TRIAL) walks the ring counting CRC-valid records for a given ISA; MU-EXEC-CAMPAIGN's signature changes to accept a start-idx and seeds MU-RUN-ID/the DO loop from it. Each RUN-*-CAMPAIGN entry word now calls DOE-RESUME-COUNT before launching. Both block-namespace-checked to fit existing headroom before committing to the design -- no new blocks needed. Real bug caught by the build, not shipped: an implicit compiler-inserted alignment byte before slot_crc silently broke the hand-computed trailing pad size (doe_trial_slot_size_check failed to compile). Fixed with an explicit alignment field, matching log_slot_t's own zero-implicit- padding discipline. extract_doe_region.py now verifies both CRCs with the REAL CRC-64/XZ algorithm from block_subsystem.c's compute_crc64() (ported and verified bit-for-bit against a native C reference this session), replacing §XXXV.11's incorrect guessed implementation. Verified: clean compile on all 3 ISAs (amd64/aarch64/riscv64 -- amd64 verified via isolated build only, not boot, since the real per-ISA campaign is currently live on the only QEMU instance this project's own rule allows), both capsules pass mkcapsule --lint, CRC64 bit-exact via native reference. Live boot-verification explicitly deferred until that campaign finishes or is interrupted -- not claimed as tested when it wasn't. Found (not missed) a real compatibility consequence: the running campaign's data is in the old pre-CRC format, so it reads as "corrupt" under the new extractor and DOE-RESUME-COUNT will resume it from 0, not mid-campaign -- no data loss, cheap redundant re-run of ~1-2 trials. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BWpNjdwPtFLuVLaAq44L9K |
||
|
Robert Allan JamesandClaude Sonnet 5
|
2da746c01c |
Build DOE-PERSIST-TRIAL: block-backed DoE campaign persistence, live-verified
FABRIC-3.md §XXXV.3/.4 designed this and it was never built -- two live campaigns got launched relying entirely on a live serial-log tail before this was caught. doe_region.c/.h mirrors log_region.c's own growable-ring pattern (own devblock_from_top fence at 98, past log_region's ceiling at 97) to persist one trial-summary record per completed trial straight to disk/artemis.img, surviving past QEMU exit with no host required. Verified end to end: booted amd64, called DOE-PERSIST-TRIAL at the console, clean BYE, then read the raw disk bytes back with QEMU fully dead -- confirmed the exact values passed in. Wired into both multiuser-doe.4th and per-isa-doe.4th's trial markers. Clean build, zero new warnings, all 3 ISAs; mkcapsule --lint passes both edited capsules. FABRIC-3.md §XXXV.10 documents the fix and the root-cause correction: two campaigns were launched on an unbuilt persistence design before this was caught and fixed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BWpNjdwPtFLuVLaAq44L9K |
||
|
Robert Allan JamesandClaude Sonnet 5
|
94215e8b47 |
Fix two catastrophically heavy workloads found running the real campaign
The full 360-trial campaign was launched, then killed after 4h39m of CPU time with zero trials completed -- still stuck on the very first touch of the very first trial. Root cause, quantified from the workload's own source, not estimated: RUN-CHAOS5 (workload-5.4th) is 1000000 0 DO CHAOS-FIELD CHAOS-RIPPLE LOOP, multiplying out to ~2.4 trillion word executions for one call -- ~495 days at the observed rate. Never designed to be called to completion as a single touch in a repeatedly-birthed worker. A second problem found computing the fix rather than discovering it mid-run again: workload-1.4th's own birth-time self-execution (20 SQUARE-WAVE + 1500 SQUARE-BURST + 100000x MICRO-BURST, all three run automatically at capsule load) sums to ~875 million words -- ~4.3 hours just to birth one worker -- and worker index 1 always maps to it in heterogeneous mode, landing in half the campaign's cells regardless of concurrency level. Fix: two new capsules, workload-1-lite.4th and workload-5-lite.4th, carrying the same word bodies verbatim but a bounded self-execution tail, comparable in scale to the campaign's other workloads. The originals are untouched; only multiuser-doe.4th's own WL-CAPSULE/ WL-ENTRY index 1 and 5 mappings were repointed. Verified live before relaunching a third time: the actual worst case in isolation (5 0 998 MU-RUN-TRIAL, concurrency=8 heterogeneous, includes both fixed workloads plus RUN-OMNI) completed in ~20 minutes wall-clock, Hera stayed healthy throughout. Clean 3-arch qemu boot. Reps reduced 60 -> 30/cell (Bob's call after seeing the real per-trial cost) -- still matches the project's "rule of 3's" DoE convention (same as ACL-RWT's own 30 reps). 6 cfgs x 30 reps = 180 trials. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BWpNjdwPtFLuVLaAq44L9K |
||
|
Robert Allan JamesandClaude Sonnet 5
|
29f91f9531 |
multiuser-doe.4th: the campaign trial-loop capsule, verified live
Builds the experimental control Bob correctly identified as still missing after HB-ON/HB-OFF (§XXXIII.5): walk the shuffled matrix of concurrency-level x workload-mode cells, birth the right worker count per cell, drive each with two VM-EXEC touches, check VM-ERROR?, kill them, print a trial marker. Built entirely from existing primitives (WORKER-BIRTH, VM-EXEC, VM-HEAT, VM-ERROR?, KILL, HB-ON/HB-OFF) plus doe.4th's own RUN-MATRIX/SHUFFLE-MATRIX pattern -- no new C primitives. Real capsule-format bug found and fixed: a first draft, chunked purely by a fixed 16-line count with no regard for word boundaries, split several CASE...ENDCASE structures and one oversized colon definition across Block headers. Result was a cascading [CAPSULE][DEFER] failure from the first split forward -- every subsequent line failed to compile, and MU-RUN-TRIAL was never actually defined (confirmed: UNKNOWN WORD when called). Root cause traced to capsule_loader.c directly: a :...; word and any control structure inside it must fit entirely within one 16-line block -- the loader's per-block compile pass has no persistent record of an open CASE's (or an overlong definition's own) state across a Block boundary. Not previously documented anywhere in this project's capsule-authoring guidance. Fixed via manually curated block boundaries and factoring oversized bodies into smaller helper words. Reps ratified at 60/cell (not the 10 first drafted), matching this project's own "rule of 3's" DoE convention (ACL-RWT's 3 seeds/30 reps, std79's 3x9x3). 6 cfgs x 60 reps = 360 main-block trials. MU-MAX-REPS raised 20 -> 63 for run-matrix headroom. Verified live on amd64: one isolated trial (0 0 999 MU-RUN-TRIAL) produced two real concurrent births, two clean kills, and the exact expected marker (MU-TRIAL run=999 cfg=0 rep=0 nw=2 mode=0 fail=0). Hera stayed healthy throughout. Clean 3-arch qemu boot. Not yet run: the full 360-trial MU-EXEC-CAMPAIGN itself (a genuinely long-running action under TCG, deliberately not started without explicit confirmation) or the WIREBIND-automation fixed arm. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BWpNjdwPtFLuVLaAq44L9K |