FABRIC.md: item 4.5d -- fortification and putc/getc fixed, PM Timer stall now blocks

Finding 2 (putc/getc) fixed via shim.c backfill (previous commit). With
both Finding 1 (-U_FORTIFY_SOURCE) and Finding 2 fixed, amd64 links clean
at -O2 -- rigorously confirmed zero new warnings by diffing normalized
warning text between -O0 and -O2 builds (empty diff, ~3040 pre-existing
warnings in vendored code unchanged).

New Finding 3, not fixed, now blocking: amd64 boot stalls for minutes
inside calibrate_tsc_with_pmtimer() (timer.c:560-589) at -O2 -- a
mainline busy-wait loop reading the ACPI PM Timer via genuinely-volatile
inl() until 1000 real ticks elapse, bounded by a 5M-iteration timeout. A
one-shot diagnostic probe (reverted after capture) caught exactly one
checkpoint in 55 seconds of observation, then nothing -- not yet
root-caused whether this is the 5M-iteration timeout itself taking several
minutes to exhaust under -O2, or a genuine non-terminating condition.

Makefile.starkernel reverted to -O0 again; nothing broken landed in
history. Routine artifacts from this session's boot attempts included.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Robert Allan James
2026-08-11 11:14:52 -04:00
co-authored by Claude Sonnet 5
parent 37eec5aaa1
commit 7df2e1bae3
10 changed files with 36722 additions and 28 deletions
+29
View File
@@ -5570,6 +5570,35 @@ document and committing that amendment as its own item.*
> builds entirely) rather than a mechanical flag. **`Makefile.starkernel` reverted to the
> committed `-O0` state** (the change was uncommitted, so a plain `git restore` — nothing
> broken is in the tree or history). 4.5d cannot complete until this is resolved.
>
> **Finding 2 fixed 2026-08-11:** backfilled `putc()`/`getc()` in `shim.c` as thin wrappers
> reusing the existing `putchar()`/`getchar()` implementations exactly (`putc`
> `console_putc` via `putchar`; `getc` → the existing "no stdin in kernel" `-1`/EOF stub via
> `getchar`) — Captain Bob's chosen approach, not new behavior. Verified: with both
> Finding 1 (`-U_FORTIFY_SOURCE`) and Finding 2 fixed, amd64 links clean at `-O2` with zero
> *new* warnings — rigorously confirmed by diffing normalized warning text between an `-O0`
> and an `-O2` build (`diff` empty; all ~3040 pre-existing warning lines, in vendored
> VM-core code already downgraded from `-Werror` by `VMCORE_CFLAGS_COMMON`, are byte-for-byte
> identical between the two, not introduced by this work).
>
> **Finding 3, NOT fixed, blocking this item: amd64 boot stalls for minutes inside PM
> Timer TSC calibration at `-O2`**, with Findings 1 and 2 both fixed. Serial log stops dead
> at `Timer: CPUID frequency unavailable; trying PM Timer...` — everything before that point
> (console, PMM, VMM, IDT, APIC, I/O APIC, i8042) comes up identically to the `-O0` boot.
> This is `calibrate_tsc_with_pmtimer()` (`arch/amd64/timer.c:560-589`), a mainline-only
> (pre-interrupt-enable) busy-wait loop reading the ACPI PM Timer port via `inl()`
> (genuinely `volatile` inline asm, confirmed not compiler-eliminable) until it observes
> 1000 real PM-timer ticks elapse, bounded by a 5,000,000-iteration hard timeout. Added a
> one-shot diagnostic probe (per this document's established write/run-once/capture/revert
> discipline) printing `iters`/`start`/`cur`/`delta` every `0x100000` iterations: exactly
> one line fired (`iters=0 start=9245289 cur=9245344 delta=55`) in a 55-second bounded
> observation window, then nothing — the loop never reached its next million-iteration
> checkpoint. Not yet root-caused: this is consistent with either the 5,000,000-iteration
> timeout itself taking several real minutes to exhaust (implying each iteration got far
> more expensive under `-O2`, mechanism unknown) or a genuine non-terminating condition;
> the evidence gathered doesn't yet distinguish the two. Probe reverted after capture, not
> left in the tree. `Makefile.starkernel` reverted to `-O0` again; nothing broken landed.
> 4.5d cannot complete until this is resolved.
- [ ] **4.5e — Three-arch acceptance boot with optimization enabled.** Depends on 4.5d. This
is the actual gate, per CLAUDE.md's non-negotiable acceptance criteria — a kernel that has