108 lines
6.2 KiB
Markdown
108 lines
6.2 KiB
Markdown
# M11 stress validation
|
||
|
||
[Stress-test usage and physical procedure](stress-testing.md) · [Implementation ledger](implementation-status.md)
|
||
|
||
M11 software acceptance passed on 2026-09-21. The expanded twelve-device suite
|
||
passed in `out/m11-vm.o1c_tqiv/`, including the explicit readiness gate and
|
||
diagnostic collector. The public `make stress-test` passed all six initial media
|
||
failure cases in `out/m11-faults.g5uw_jao/`. The strengthened final
|
||
`make media-fault-test` passed in `out/m11-faults.hfyqoui3/`, verifying the actual
|
||
virtual-device byte counter before each interruption. `make check` then passed. Physical Pi/hub/battery tests remain deferred.
|
||
|
||
## Twelve-device evidence
|
||
|
||
The complete runs used the packaged M10 CLI rootfs and actual Pi kernel in
|
||
an isolated generic ARM VM. A protected virtual SYSTEM root and twelve USB disks
|
||
were present: one DATA and eleven distinct PROGRAM cartridges. Every identity
|
||
matched its bay through cold boot, three simultaneous hotplug/removal cycles,
|
||
rotated placements and reverse device insertion order.
|
||
|
||
Eleven direct readers each verified 32 MiB while DATA wrote and flushed 64 MiB.
|
||
All twelve measured I/O intervals overlapped. QEMU block counters confirmed the
|
||
corresponding reads/writes, so cached file reads alone could not satisfy the test.
|
||
A subsequent managed writer and its TERM-ignoring descendant ran during native
|
||
reboot. Independent host `e2fsck` passed; the entire 64 MiB payload matched its
|
||
expected SHA-256. Another boot with a different device declaration order retained
|
||
correct mapping and data, and completed native poweroff. Read-only cartridge
|
||
image hashes were unchanged.
|
||
|
||
Kernel logs from normal stress/reboot contained no detected unexpected USB reset,
|
||
controller failure, I/O error or filesystem error. This only describes the virtual
|
||
hardware used in the test. It says nothing about physical voltage, hub firmware,
|
||
cables, RP1 or a storage controller's cache guarantees.
|
||
|
||
## Startup observations
|
||
|
||
Three paired samples used the same SYSTEM and virtual controller, with either
|
||
zero or twelve USB disks. The first complete run observed:
|
||
|
||
| USB population | Kernel-to-console samples | Median |
|
||
| --- | --- | --- |
|
||
| Empty | 1907.961445, 1761.020483, 1847.460910 ms | 1847.460910 ms |
|
||
| Twelve | 1968.638224, 1998.194820, 1927.705171 ms | 1968.638224 ms |
|
||
|
||
The median device-load difference was **+121.177314 ms**, above the 100 ms review
|
||
threshold. Stage0 discovery remained approximately 23–27 ms in both scenarios;
|
||
the increased work appears mainly between s6 start and console readiness.
|
||
The unchanged getty graph has no cartridge-readiness dependency. Concurrent USB
|
||
and cartridge processing competes with startup in this two-vCPU emulator. This
|
||
is an explanation of the controlled device-load comparison, not a claim that a
|
||
code change has been proven faster or that Pi timing targets passed.
|
||
|
||
Earlier complete cold-boot pairs from interrupted test attempts observed
|
||
+122.544124 ms and +76.064782 ms; their raw reports remain in
|
||
`out/m11-vm.jcvwpxel/` and `out/m11-vm.w4oyzwje/`. They are not full acceptance runs.
|
||
The spread is retained rather than discarding slower observations. The expanded
|
||
suite then passed with medians 1900.735990 ms (empty) and 1957.588750 ms (twelve):
|
||
**+56.852760 ms**. All samples and the actual ARM comparison are stored in
|
||
`out/m11-vm.o1c_tqiv/boot-comparison.json` and `boot-review.log`. The blocked-daemon
|
||
case reached the real UID-1000 prompt with no cartridge control socket, then
|
||
completed enumeration and native shutdown after an explicit event released the
|
||
daemon. This verifies console independence under the same twelve-device load.
|
||
|
||
## Test-harness findings
|
||
|
||
The AArch64 Linux `O_DIRECT` flag differs from the x86_64 value. An initial
|
||
fixture incorrectly requested directory-only opens and failed before I/O. The
|
||
corrected ARM-only test helper performs aligned direct reads; byte checks and
|
||
block counters then passed. No target runtime change was needed.
|
||
|
||
A burst of asynchronous device-deletion events could arrive while a new QMP
|
||
monitor connection was being greeted. The shared VM helper now accepts those
|
||
events before the greeting, without treating them as command responses. Checked
|
||
serial capture executes a command once and retries only a corrupted transfer.
|
||
It preserves kernel diagnostics instead of suppressing error messages.
|
||
|
||
## Media failure acceptance
|
||
|
||
Actual-device tests passed for write EIO, flush EIO and readback EIO.
|
||
Each leaves a failed operation across daemon restart, with no SAFE marker.
|
||
Cancellation, worker death and daemon death during confirmed writing also passed
|
||
in `out/m11-faults.g5uw_jao/`. The strengthened run in
|
||
`out/m11-faults.hfyqoui3/` additionally requires at least 64 MiB in QEMU's actual
|
||
write counter while the transfer remains incomplete, retaining that counter and
|
||
job state in an interruption record. All three strengthened interruption cases
|
||
passed: each had accepted 128 MiB into the guest write path and delivered 64 MiB
|
||
to the virtual disk, with a 270532608-byte source still incomplete. Cancellation
|
||
retained its diagnostic, worker death retained a failed-completion error, and
|
||
daemon death retained a restart error. Each remained failed after another
|
||
restart, with the daemon usable and no SAFE marker.
|
||
|
||
Final logs are `out/logs/m11-final-stress-retry.log`,
|
||
`out/logs/m11-final-faults.log` and `out/logs/m11-final-check.log`. The final failure
|
||
run records input hashes and QEMU 11.1.1 identity beside its images. Runtime
|
||
packages and boot artifacts remain the verified M10 builds; M11 adds tests and
|
||
physical-test tooling rather than changing the target service behavior.
|
||
|
||
## Physical acceptance
|
||
|
||
The [physical procedure](stress-testing.md#prepare-the-physical-session) covers
|
||
bay calibration, cold boot, rotated placement, concurrent I/O, orderly reboot and
|
||
poweroff, power behavior and external timing. `tools/capture-hardware` collects
|
||
read-only local diagnostics with per-command exit statuses and checksums. It
|
||
reports collection success separately from hardware acceptance. All 17 capture
|
||
commands returned success in the ARM VM, and the resulting private directory
|
||
and checksums passed inspection. The blank physical session template remains
|
||
explicitly `not_run`. None of those
|
||
physical tests has been performed in this milestone.
|