felis/fds-os

Fork 0

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Table of Contents

M11 stress validation

Twelve-device evidence
Startup observations
Test-harness findings
Media failure acceptance
Physical acceptance

include_toc

include_toc
true

M11 stress validation

Development reference and historical context. For current operating instructions, use the user manual. Acceptance applies only to the source and artifacts identified in each record.

Stress-test usage and physical procedure · Implementation ledger

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 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.

FDS/OS

Home · Overview · All pages

Start here

Use the computer

Install and maintain

Build and contribute

Home · All pages · Edit the wiki · Source repository

Maintained directly in the fds-os.wiki repository. Historical acceptance applies only to the source and artifacts identified in each record.