BlackMark bf9b86d2fc build: the libavr pin advances 29 commits, and selfwrite stops being flaky ...

dc1e87d -> aec9955. Every generated workflow green on all 37 chips, and no
image moves: this loader uses uart, spm, eeprom and startup, and the library's
advance is in i2c, the uart ring's field order, percent_t's constructor and a
spare-vector stub, none of which pureboot links.

The gate came back red on atmega16 and atmega32a, both pureboot.selfwrite, and
the advance is not why. Measured at both pins over twenty runs each: 2/20 red
at dc1e87d and 1/20 at aec9955, so the flake predates the pin and the eight
clean runs that first suggested otherwise were luck.

The cause is in the test. It writes the sealed erase and waits with
read_exact(2, 2.0) - but the loader issues its verdict *before* the SPM, as
the comment above that line already said, so the reply arrives while the erase
has not happened and device.stop() then races it. That is why every failure
was fast (0.39 s, 0.64 s) and every pass slow (2.44 s): the runs that passed
were the ones whose read timed out. The second mode is the same race seen from
the host - the loader erases its own command loop mid-reply, the pty closes,
and errno 5 escapes an except that names only pb.Error.

So the wait is a settle nothing may shorten, and a closing pty ends it rather
than escaping it. A fixed settle is still wall clock against the simulator's
progress through it, which is load-dependent - it measured 1/10 red with the
machine saturated - so the scenario is attempted with a doubling budget and
the claim stays exact: a loader that does not erase fails every attempt.

0/30 quiet and 0/20 with all four cores saturated, against 2/20 before.
Red-checked by settling for zero, which still reports the erase never landed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-23 03:06:12 +02:00

5.5 KiB

Raw Blame History

View Raw