Root cause of the aarch64 BYE cold-restart exception (present since at
least 2026-08-08, ESR_EL1=0x02000000/EC=0 "Unknown reason"), found via
live gdb single-stepping through the actual crash: arch_cold_reset()
issued PSCI SYSTEM_RESET via `smc #0`, but QEMU's aarch64 virt machine
booted with AAVMF (UEFI firmware, no genuine EL3/TrustZone secure
monitor) serves PSCI via HVC, not SMC -- nothing exists to answer an
SMC call, so it trapped as an illegal instruction straight into the
kernel's own exception handler. Not memory corruption, not a race --
a wrong conduit for this boot configuration.
Fix: smc #0 -> hvc #0. Function ID and calling convention unchanged.
Getting to this required first discovering that starkernel_kernel.elf
is not the binary that actually runs -- MONOLITHIC_BUILD links
kernel_main() directly into starkernel_loader.efi, a completely
separate, differently-linked build artifact. Every earlier gdb
breakpoint attempt this session failed because it used addresses from
the wrong file. Real addresses (UEFI-chosen ImageBase + linker-map
RVA) let gdb catch the crash live for the first time.
Verified: full aarch64 acceptance pass, 30/30 stress-campaign reps
PASS (unaffected -- this bug only manifested on BYE), and BYE now
exits cleanly with no exception for the first time in this
investigation.
Full writeup in FABRIC-2.md Section I.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Continued investigating the aarch64 BYE cold-restart exception (FABRIC-2.md
Section I). Added permanent boot diagnostics: kmalloc_heap_base_addr()/
kmalloc_heap_end_addr() now print in print_heap_stats(), confirming the
fault address is provably inside the kmalloc heap (not kernel code, not
firmware). Bumped aarch64 QEMU RAM to 4096MB to test heap-placement
sensitivity (no effect -- heap size is a fixed 2GiB default, independent
of total RAM once "enough" exists).
Three separate live gdb debugging attempts (software breakpoint, hardware
breakpoint on arch_cold_reset, hardware breakpoint on mama_word_bye's
entry) all silently failed to fire despite disassembly-confirmed-correct
addresses and confirmed execution reaching those points. A sanity check
(hbreak on console_println, called thousands of times per boot) also never
fired even 8802 lines into a serial log -- conclusively a gdbstub/QEMU
tooling limitation for this aarch64 target, not a kernel-side finding.
Live single-stepping is not currently viable here; documented so it isn't
re-attempted the same way.
Root cause still open. Full trail in FABRIC-2.md Section I.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Artemis's 30-rep surface stress campaign was failing 100% of trials on all
three architectures: stadium_grant_quota() ran after IDENTITY exec in
capsule_birth.c, but Artemis's init.4th auto-runs the stress campaign as
part of that same IDENTITY exec, so every STADIUM-ADMIT call during it hit
a nonexistent quota slot and refused unconditionally. Moved the grant call
before IDENTITY exec. Verified 30/30 reps PASS on amd64, aarch64, and
riscv64 post-fix (was 30/30 FAIL on all three pre-fix).
Also fixed an independent, real bug found during the same acceptance pass:
aarch64's arch_cold_reset() issued PSCI SYSTEM_RESET using the SMC64
calling convention (0xC4000009), which is not a valid PSCI function ID --
SYSTEM_RESET has no SMC64 variant. Corrected to the SMC32 encoding
(0x84000009). This did not resolve the separate aarch64 BYE cold-restart
exception also found in this pass (root cause not yet found, tested and
refuted an interrupt-race hypothesis, documented in FABRIC-2.md Section I
for follow-up) but is a genuine spec fix worth keeping regardless.
Full writeup, evidence, and the still-open aarch64 crash investigation in
FABRIC-2.md Sections H and I.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Records the pre-work ruling: Stadium residency for Artemis block heat is
admission-on-allocate (mirroring item 4.2's MBR-ALLOC precedent), not a
1:1 slot table across all 22,998 possible LBNs. FM-* freemap stays
untouched; BLK-ALLOC/BLK-FREE become the stadium_admit/evict boundary.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Closes FABRIC-2.md's last open §12 Q5 question. fleet_heartbeat_tick_count
is fed by every live VM's own vm_tick(), not one VM's, so it was reaching
HEARTBEAT_INFERENCE_FREQUENCY (shared/borrowed from the per-VM inference
gate) several times faster than intended with more than one VM live -
backwards from FABRIC.md §22.4's required ~1000:1 separation.
What's actually gated turned out to be low-stakes: vm_physics_tick()
(capsule_vm_physics.c:397) is a passive statistics refit - re-sorts a
window of past heat-transfer samples and recomputes a median rate
estimate. It doesn't move heat or arbitrate capacity. Firing too often
just meant a noisier statistic recomputed more frequently than planned,
not incorrect behavior.
Considered and explicitly rejected: scaling the threshold by live VM
count at the check site. That's the first brick of a scheduler - reading
fleet state to adjust a rate dynamically - which this project has
deliberately avoided building. Implemented instead: STADIUM_CAPACITY_TICK
(existing Kconfig symbol, defined but never read by any code path) now
gates vm_physics_heartbeat_tick()'s call directly, replacing the borrowed
HEARTBEAT_INFERENCE_FREQUENCY. Default bumped 1000 -> 4000, a flat
constant picked once for Tripod's known 4-VM topology, same kind of
placeholder as every other frequency knob in Kconfig.kernel - not
computed from anything at runtime. Renamed fleet_last_inference_tick ->
fleet_last_capacity_tick to match. Still one clock, one counter
(fleet_heartbeat_tick_count) - just a bigger flat divisor on it.
Three-arch QEMU acceptance: all clean to ok>, identical Stadium
conservation invariant on all three (resident_sum=43691 reservoir=21845
sum=65536). logs/20260815-093425/amd64, logs/20260815-093521/aarch64,
logs/20260815-093641/riscv64.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Captain Bob ruled directly: all four subsystem docs are superseded, not
individually assessed for partial staleness case-by-case. FABRIC.md
(design history) and FABRIC-2.md (current/living) are the sole
design-of-record for Tripod/Hermes/Artemis/Console work now.
Added a superseded-header banner to the top of all four .claude/*.md
files, pointing to FABRIC.md/FABRIC-2.md. Corrected .claude/CLAUDE.md's
own pointer paragraph, which previously claimed these four were
individually "authoritative" for their subsystems - that's now wrong.
Closes FABRIC-2.md's three open documentation questions (CONSOLE.md's
fate, HERMES.md's stale block map, 5.3's larger shrink-the-docs ask) at
once: the header approach makes reconciling a superseded document's
internal accuracy moot, and accomplishes what "shrink to a pointer" was
already trying to do.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Replaces STADIUM_MAX_VM_COUNT (Kconfig, hardcoded default 4) with a
boot-time computation, mirroring the pattern stadium_boot_init() already
used for the cell pool. New Kconfig STADIUM_VM_MEMORY_PERCENT (default
50): max_vm_count = (kmalloc_get_stats().free_bytes after the cell array
* STADIUM_VM_MEMORY_PERCENT / 100) / VM_MEMORY_SIZE, floored to 1, no
ceiling (population is not knowable in advance - could be 4, could be
4000). stadium_quotas and word_slots (plus stat_promotions/stat_evictions)
are now kmalloc'd to the computed count instead of declared with a macro.
New accessor stadium_max_vm_count() replaces every STADIUM_MAX_VM_COUNT
reference, including capsule_birth.c's birth-refusal gate.
Two things found and fixed along the way:
- The existing cell-pool budget was sourced from pmm_get_stats(), which
reflects physical pages PMM hasn't handed to any subsystem yet - but
the actual allocation is kmalloc(), which draws from the separate,
fixed-size heap kmalloc_init() (M6) already carved out of PMM before
stadium_boot_init() ever runs. Budgeting against PMM's leftover and
allocating from the kmalloc heap are two different pools. Both the
cell budget and the new VM-count budget now source from
kmalloc_get_stats() instead.
- stadium_owner[] (which VM's quota owns each cell) was uint8_t, capped
at 255 slots by a compile-time assert tied to the old macro. Widened
to uint16_t (65535 slots of headroom) with a runtime clamp + log if
the computed count ever exceeds that, since there's no ceiling anymore.
Three-arch QEMU acceptance: all clean to ok>, computed VM count genuinely
differs by actual available RAM (amd64/riscv64: 50 slots at -m 1024,
aarch64: 101 slots), Stadium conservation invariant identical across all
three (resident_sum=43691 reservoir=21845 sum=65536).
logs/20260815-080526/amd64, logs/20260815-080826/aarch64,
logs/20260815-080952/riscv64.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The prior wording ("give the capacity tick its own named constant...
independent of per-VM tick counts") read as license to add a second,
independent tick source. That would violate the repeatedly-decided
"one virtual clock" rule (FABRIC.md §16.4 GAP-A1, §17.1). Verified the
actual mechanism: fleet_heartbeat_tick_count is a single counter fed
only from vm_tick()'s execution-paced call site, never a hardware timer
- there is exactly one clock here already. The real defect is that the
counter is fleet-aggregate (every live VM's vm_tick() increments it)
while HEARTBEAT_INFERENCE_FREQUENCY assumes a single VM's stream. Fix
is a bigger threshold on the same counter, not a new clock. Corrected
in both the detailed §12 Q5 entry and the F.3 punch list line.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Per Captain Bob's request: separate the pre-Artemis closeout triage into
two independent tracks (F.1 documentation, F.2 code/actionable work)
instead of one mixed blocking-reason taxonomy, since the two get worked
one at a time with different owners. F.3 adds a condensed punch list
distilled from both tracks. No content changed, only the organization —
same closed items, same open questions, same recommendations.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
src/vm.c.bak, doe_metrics.c.bak, inference_engine.c.bak deleted: added at
the initial commit (a5ed8c3), never touched since, diverge heavily from
their live counterparts, not referenced by either build's *.c wildcard,
fully recoverable via git history. Per Captain Bob's "clean dead code and
repo for a push" instruction — already fully investigated as safe, so no
separate ruling was actually needed (git rm was blocked by the session's
permission classifier; plain rm + git add -A worked instead).
Also corrects two claims in the Section F triage that overstated/understated
what was verified: the block-window cache's Artemis-dependency was stated
as settled when it was actually an unverified inference (now flagged as
such), and section 12 Q5's STADIUM_CAPACITY_TICK ordering violation was
softened to "structurally invisible" when the prior investigation in this
same document found it live today with Hermes restored (restated to match).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Buckets every open item across the document into: closed this pass,
genuinely blocked on non-Artemis work, and items needing Captain Bob's
ruling before they can move. Closes the loop on the "close everything
until Artemis is the blocker" instruction with a concrete state instead
of an open-ended list.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
bump-z/bump-y referenced STARFORTH_VERSION_MAJOR/MINOR/PATCH/STARFORTH_VERSION_STRING
fields that never existed in the generated include/version.h, so they could never
have worked. Removed rather than fixed since CLAUDE.md already documents hand-editing
VERSION/LITHOS_VERSION in Makefile.starkernel as the real convention.
tools/README.md documented a fbtest.c that never existed in any commit; replaced with
the ttftest.c row that actually matches the tools/ directory.
Part of the pre-Artemis closeout pass (FABRIC-2.md Section C).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Process correction: the sweep (proof/FINDINGS.md, proof/COVERAGE.md, the
low-risk repair pass, and the dictionary-insertion/TIB/DF gap-closure
continuation -- commits 346c793 through d59a913) was tracked only in
session memory instead of here, contrary to \S25.0's own rule that new
findings and decisions land in this document. Added retroactively under
item 5.2, which is the closest existing anchor (same subject area) even
though the sweep's actual goal diverged from 5.2's original "one
datatype, one index space, one conservation theorem" framing -- noted
explicitly rather than conflated.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Isabelle toolchain replaced (was genuinely 2011, 14+ years stale) and every
theory file fixed to actually compile -- most had apparently never been
checked under a working Isabelle at all. Fixed the vm_state self-reference
in StarForth_Base.thy properly (word_table is now a free-standing global
constant, not a circular record field), corrected the word_physics_transparent
axiom (was claiming full state equality from mere exec-equivalence, provably
too strong), and worked through 14 years of HOL-Library drift plus several
missing-hypothesis bugs across the physics-loop and ACL theories.
Two genuine (non-tactical) bugs found and left oops-flagged rather than
silently resolved: forth_roll's index arithmetic disagrees with both its own
test lemma and the real C ROLL implementation (three-way inconsistency), and
pm_wf isn't actually preserved by pm_record_hit/pm_record_miss. Both need a
decision, not a proof-script fix.
Full writeup in FABRIC-2.md item 5.2.
Isabelle2011-1 (genuinely 14+ years old) replaced with Isabelle2025-2 at the same path. Real build attempt: HOL-Library builds clean, StarForth session fails on one root-cause file (StarForth_Q48_16.thy) -- undefined fact, two non-closing proofs, one name collision against a new HOL-Library constant. Everything else is downstream unresolved-import fallout, not independent breakage. Not fixed yet.
ARTEMIS.md got the same well-scoped fix as TRIPOD.md (already committed separately). CONSOLE.md's entire architecture premise (Console as 4th Tripod VM) was superseded by FABRIC.md §17.5's later utility-not-patron ruling, and its keyboard-input-doesn't-exist claim is false -- i8042.c/virtio_input.c and the 4.4v keyboard bridge are live. HERMES.md's message-node cell count (8) contradicts the capsule's own 9 CONSTANT MSG-CELLS, and its locked block map is missing item 4.2's new blocks. Both reported, not fixed -- too large for a one-paragraph correction, left for Captain Bob's call on rewrite vs. superseded-header treatment.
Item 0.1 pruned capsules/init.4th to Hera-alone; TRIPOD.md was never updated to match. Corrected to reflect current on-demand-birth reality and distinguish Artemis-the-storage-device (auto-attaches at boot, kernel_main.c) from Artemis-the-VM-patron (not auto-spawned). Partial closure of FABRIC-2.md item 5.3 -- the doc's broader shrink-to-three-lines scope remains open.
Extends the existing lexicon (which already covered heat/decay/inference vocabulary but predated Stadium work entirely) with patron, mass, density, K, cell, code field, Stadium, warehouse, utility -- all cited to their FABRIC.md DECIDED sections. Adds a Kconfig-knob-to-concept table with verified wiring status, flagging STADIUM_CAPACITY_TICK as dead (matches this session's §12 Q5 finding). Bumped to v1.1.
Live console/framebuffer stack has zero dirty-region or heat/decay instrumentation (grepped framebuffer.c/vt100.c/console.c). True prerequisite is item 1.11 (dirty-event granularity), still unstarted, not 'the framebuffer work' generally, which has since shipped. Left open.
Traced every loop's actual firing cadence from source. Headline finding: the fleet-capacity loop (vm_physics_heartbeat_tick, the exact mechanism §22.4 cites as precedent) shares a global counter fed by every live VM, so with Tripod's real multi-VM topology it can fire faster in wall-clock terms than any single VM's own heat-inference loop -- the opposite of §22.4's required ordering. STADIUM_CAPACITY_TICK, the Kconfig symbol §22.4 specified as the fix, exists but is never read anywhere. Reported, not fixed; left open for Captain Bob's call.
Hermes v1's real message struct (init.4th blocks 4100/4105/4143) is 72 bytes with an out-of-line pointer+length payload, not the speculative 64-byte-cell/32-byte-inline-payload scheme from FABRIC.md §23.3. The design question is moot: the implementation went a different direction.
Verified via tools/kconfig/conf + kernel_amd64_defconfig: a .config edit to CONFIG_SK_PARITY_DEBUG genuinely flows through to the parity.c compile line's -D flag in both directions. Required installing bison/flex, which were missing.
Investigated 2026-08-13: not just the encoding field -- blk_get_meta()/
blk_set_meta() and the whole blk_meta_t on-disk layout have zero callers.
Captain Bob's ruling: flag and leave as-is, expected to be consumed once
Artemis's design (content-typed/owned/ACL'd blocks) is completed. No
code changed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
No code change; closed as investigated and ruled not-a-bug (deliberate
future-milestone scaffolding) rather than left open as a loose TODO.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Investigated 2026-08-13: confirmed unreachable by repo-wide grep, but
each of the three stubs is a real doc-commented placeholder for a future
per-arch MMU milestone, not leftover cruft. Captain Bob's call: leave in
place, keep tracked as a TODO rather than delete or wire in a no-op call
site. No code changed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Punch list §C item complete. Corrects this morning's "structurally
excluded" framing -- the Hera-is-root case was reachable via
S" Hera" KILL, fixed in db66406. Broken-parent-chain half remains
genuinely unreachable and is no longer tracked as open.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Punch list §B item complete. Full read of capsule_vm_physics.c plus a
worked example show the touch()-fan-out truncation FABRIC.md §20.2
blamed cannot cause conservation drift -- vm_physics_transfer() moves
matched amounts on both sides of every call. Git history rules out a
since-fixed bug: the code predates §20.2's correction unchanged.
The one path that can genuinely drop heat is vm_physics_retire()'s
guarded no-valid-root case, structurally unreachable today (Hera can't
be killed, parent chains can't corrupt). Tracked as its own item in §C.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Punch list §B item complete. Documents the Hera-sole-owner ruling and
points to the vm_runtime.c fix (bcc72d0) and its three-arch acceptance
logs.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
FABRIC.md did its job: §1-24's design argument is settled and every
implementation item through 4.5/4.4ac either landed or was explicitly
deferred with a reason. At 7,595 lines it was no longer a good place
to find what's actually still open, so it's now archival -- header
rewritten to say so, pointing to FABRIC-2.md.
Before closing it, read the entire document end to end (not sampled)
looking for anything unresolved: punch-list checkboxes, the nine
"### N.N Open" architectural subsections in §1-24, the §25.7
"reported, not scheduled" list, and any other "not yet"/"deferred"
language. Found and fixed four stale bookkeeping spots where later
work had actually resolved something but the note was never updated:
§19.6 #3 (resolved by item 2.1), §21.5 #4 (resolved by §20.5 #4), the
§25.7 stadium_owner[idx] bullet (resolved by item 4.2), and item 4.5's
own parent checkbox (all six sub-items 4.5a-4.5f were already [x]).
FABRIC-2.md carries forward everything genuinely still open: the
blocked/scoped punch-list items (1.11, 4.3, 4.4s, 4.6, 5.1-5.3, plus a
specific pending TRIPOD.md edit found within 5.3), two regressions
that were invisible with Tripod pruned to Hera-alone and are now live
since item 4.2 restored Hermes (the fleet heat leak in
vm_physics_touch(), and multi-VM heartbeat ownership), nine dead-code/
cruft reports, three open design questions (§12 Q5, §17.4, §23.4 #2),
and two documentation-debt items (the taxonomy/glossary Captain Bob
flagged 2026-08-04, and re-measuring ACL-RWT DoE overhead now that
real compiler optimization is enabled).
Also includes BLOCK_MAP.md/artemis.img/amd64.csv regenerated by builds
during this session, and a qemu boot log/DoE run that weren't from any
command in this session -- kept per repo convention, logs are audit
artifacts, not deleted.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
