screen_loader_lines reads the firmware's text mode off the panel, counts its rows where the logo never is, and judges the panel once two dumps agree

[Japabu]

Aims to fix the screen_loader_lines red on main. The loader is correct. The test's row counter was counting the firmware's boot logo.

Unproven until a nightly shows it. The setup that went red is CI's KVM with Debian OVMF in 240x56. That claim holds only once gh workflow run nightly.yml --ref wt/toyos-loaderlines runs with its headSha equal to this PR's head. On the shard that runs the test, its log must carry these two lines, in this order:

  [screen] the panel carries all 41 rows the console put at its edge in its 240x56 text mode
  PASS  screen_loader_lines

The review quoted the first line with , 14 of them after the GOP query at the end. This head drops that clause (see the fix below), so the line above is what the test prints now. Any mode other than 240x56 makes the root-cause table below wrong, even on a green run.

Root cause

The red. Main's nightlies 36550208853 (7e151819e) and 36696295750 (ace064f9d, guest shard 8) were red, and so were the branch nightlies 36600425263 and 36709239346. All four gave the same numbers:

FAIL screen_loader_lines: the panel carried 26 rows at the GOP query and 41 at the loader's last line, a growth of 15, where the loader printed 14 lines between them, 14 rows at 240 columns

The last green runs were 36400924827 (main a7cd32765, shard 4) and 36496779560 (shard 6). Both printed the panel grew 16 row(s) across the GOP query, 26 to 42, for 16 line(s) printed. The only loader change between a7cd32765 and 7e151819e is #583.

The mechanism. OVMF draws the TianoCore logo (BootLogoEnableLogo, which also turns the cursor off) after the console's last ClearScreen. The logo is Logo.bmp, 193x58 pixels, centred on the panel. The graphics console then draws its 8x19 cells, and it overwrites only the cells a line reaches. Main's text_row_bands counted bands of lit scanlines across the whole width, and the logo broke that count in two ways:

• A short row printed over the logo joins it into one band taller than the pitch. That band is refused, so the row is not counted.
• A row printed across the logo's columns erases the logo within its own cell row. The rows next to it are then no longer joined to the logo and count again.

1090cf6ea (in #583) removed the loader's 128-column RTC zone line. Since then the 165-column Black box line lands on the logo's second row and erases it there, so at the last line the GOP row counts again and the growth comes out one more than the lines printed. The model below reproduces all of these numbers.

The firmware's text mode differs by host

Round 1 read the panel's first 8 cells from x=0. On the dev host that found no lit pixel at all: the orchestrator's runs of efc6e0c21 were red three times out of three with the panel carries 0 band(s) of lit scanlines, alone, under the exclusive-GOP control, and in the whole suite.

The reason is that edk2's graphics console centres its text mode on the panel (InitializeGraphicsConsoleTextMode's DeltaX and DeltaY). It wraps a line when its row is full and scrolls the text area once the cursor passes the last row (GraphicsConsoleConOutOutputString). Which mode it draws in is the firmware build's choice:

Host	Firmware	Text mode	Text starts at	The loader's console
CI guest shards	Debian ovmf-generic	240x56	x=0, y=8	41 rows, no scroll
dev host	Homebrew QEMU 11.1.1's edk2-x86_64-code.fd	80x50	x=640, y=65	58 rows, so the panel scrolls and keeps the last 49

Where these modes come from. CI's serial names its mode. Nightly 36696295750, job 109873180506, carries the terminal's ESC[8;056;240t before its last ESC[2J. The dev host's mode comes from a pixel model built from edk2's source (GraphicsConsole.c, LaffStd.c, BootLogoLib.c, Logo.bmp): its cells, wrap and scroll, fed the red nightly's console and counted with main's whole-width counter. For every mode edk2 offers on a 1920x1080 panel, the model's counts at the GOP query and at the last line are:

Mode	80x25	80x50	100x31	128x40	160x42	240x56
Model: GOP query, last line	24, 24	37, 47	29, 30	29, 36	25, 39	26, 41

• CI recorded 26 and 41. Only 240x56 gives that pair, and it is the mode CI's serial names.
• Main's local passes in the orchestrator's logs recorded 37 to 47 (5 runs) and 38 to 47 (8 runs). Only 80x50 comes close. Its 37 and 47 come from the CI console, which is not the console those local boots printed, so it matches them closely, not exactly.
• 80x50 also explains the round-1 red: its text starts at x=640, past the first 8 cells.

The fix

• Ppm::firmware_text_mode reads the mode off the panel. It picks from the modes edk2 offers there (TextMode::offered: UEFI's 80x25 and 80x50, mGraphicsConsoleModeData, and the whole panel).
  • The mode's first cell column must hold the panel's leftmost lit pixel, because every row starts there.
  • Its rows must hold everything lit in its first 8 cells. That rule is what separates 80x25 from 80x50.
  • If no mode fits, or more than one does, the panel is refused by name.
• Ppm::edge_rows reads each of that mode's rows in its first 8 cells, cell by cell. A glyph never leaves its cell. A centred logo narrower than 512 pixels never reaches those cells in any mode 80 or more columns wide. Bands, the median pitch and their refusals are gone.
• TextMode::panel reads the same rows off the console. It takes every line since the last ESC[2J as it came off the serial and wraps it at the mode's columns. A line that fills its last row leaves a blank row after it, which is edk2's wrap followed by the line's own CRLF. A line feed on the last row scrolls the text. The review's note had TextMode::printed folded into it. printed's one other reader was the success line's N of them after the GOP query, which no judge reads, so that clause is gone too.
• The console's lines are not stripped of CSI sequences. After the last ESC[2J the only sequence is the leading cursor-home. The review measured that it changes no row on either console. At 240 columns it lengthens the first line from 116 to 126 columns, still one row. At 80 the line takes 2 rows either way, and both scroll off.
• The panel is judged once two dumps in a row agree. uefi-services' println! sends a line's CRLF as its own OutputString, and edk2 scrolls on that line feed at the last row. If ConSplitter writes the terminal before the graphics console, the serial line is complete before the panel has scrolled. The test therefore dumps the panel back to back, with no delay, until two consecutive dumps carry the same text mode and row map, and judges that map.
  • A dump with any row that decodes in the kernel's font is refused as the kernel's repaint, as before.
  • The loop is bounded by qemu.budget(30 s), a liveness ceiling only. If the panel is still changing when it passes, the test fails and prints both dumps' maps.
  • It calls screendump directly. screendump_while takes an Fn predicate and returns only the last dump, so carrying the previous map through it would need a RefCell.
  • Not after the kernel's first record. The review's first option was to dump after the kernel's first [kernel line on the 16550. panic_console::arm commits panic console: armed and repaints the whole panel before serial::init makes the 16550 a backend. Every dump after that line would meet the refusal. Job 108841154205's serial shows that record as the first kernel line, right after Loader log: the kernel handoff begins.
• The test requires the console and the panel to agree row by row. When they do not, it prints both counts and both row maps. The GOP line's width no longer decides the columns, but the line must still be on the console.
• The exclusive-GOP control now reaches this judgement. Its panel stops before the GOP line, and the model expects every row.
• The host check firmware_rows_at_the_edge stages both real geometries with a pixel-level edk2 renderer: cells blitted whole over a centred 193x58 logo, wrapping, and a scroll that moves the text area's pixels, logo included. In each mode it requires:
  • the mode found, and both row maps matching counts derived by hand. At 80x50, 53 rows are printed, the first four scroll off, and 46 are lit. At 240x56, 50 rows are printed and 48 are lit.
  • that the exclusive-GOP control's panel, which stops after the first 45 lines, is read in the staged mode and does not carry the console's rows.

Gates

All at 6e0d7da82.

Command	Result
cargo test --test toyos-checks -- firmware_rows_at_the_edge screen_decoder	EXIT=0, 2 passed
cargo test --no-run --test toyos-build	EXIT=0
cargo run -- --ci host	EXIT=0, [ci] Host: 55 step(s), all green, checks::firmware_rows_at_the_edge ... ok
exclusive-gop.patch applied, then cargo run -- --build-only	EXIT=0; the patched tree builds, and the tree was restored

Mutations of the judge and of the control, each applied as a checked patch, built, run and reverted. Every mutant built (cargo test --no-run --test toyos-checks, EXIT=0). Each was then run with cargo test --test toyos-checks -- firmware_rows_at_the_edge, and each went red:

Mutant	EXIT	What the check said
Edge read from x=0 (round 1's bug)	101	2 modes fit at x=640 (80x25 and 80x50)
No scroll in TextMode::panel	101	80x50: carrying 46 where the console put 50
Whole row read instead of the first 8 cells	101	80x50: carrying 47 where the console put 46
No blank row after a line that fills its last row	101	80x50: carrying 46 where the console put 47
No vertical fit in firmware_text_mode	101	2 modes fit
The 80x50 control's panel given every line	101	80x50 control: carrying 46 where the console put 46
The 240x56 control's panel given every line	101	240x56 control: carrying 48 where the console put 48

The first five mutants fail on the 80x50 case before the 240x56 case runs. The last two show that the control fires in each mode on its own.

Unsure

• Two dumps have to fit between the scroll and the kernel's repaint. The kernel repaints the panel in panic_console::arm, just after ExitBootServices. Main's single dump after the loader's last line fitted in that window on CI's KVM: the red nightlies counted 41 rows there and did not refuse. Nobody has measured whether two dumps fit. If they do not, the test goes red with the repaint refusal and the kernel's decoded screen, not green.
• A dump taken mid-scroll or mid-repaint that firmware_text_mode cannot read fails at once rather than being dumped again.
• TextMode::offered copies edk2's mode table. A firmware that draws in a mode outside it is refused by name rather than counted.
• If a future OVMF left the cursor on, the equality would go red on the cursor's cell. It would fail loudly, not pass silently.
• The issue entries about this test's earlier sightings were left as they are: zero bands, zero growth, and the GOP-query race.

🤖 Generated with Claude Code

https://claude.ai/code/session_016t9wjdQkB8SH7bmfUoiy6L

[Japabu]

Orchestrator runs at 382919c (cargo test --test toyos-build -- <args>; logs orch/logs/640r2-*.log):

job	args	patch	exit	line
head	screen_loader_lines	—	0	PASS screen_loader_lines (2s)
exclusive-GOP control	screen_loader_lines	loaderlines/r2/…exclusive-gop	1	FAIL screen_loader_lines: the panel's first 8 cells carry 38 rows of text where the console put 49 there in its 80x50 text mode, row by row
whole	(none)	—	0	test result: ok. 498 passed, 498 total (360.3s)

[Japabu]

Review round 1, head 382919c5b. CI host passed at this head (run 36750167870, job 110006442089, whose log shows checks::firmware_rows_at_the_edge ... ok). The only guest evidence is issuecomment-5916132737: the dev host, TCG, Homebrew edk2, 80x50.

Net lines: +282 −130 = +152. The harness and guest test (tests/common/screen.rs, tests/toyos.rs) are +182 −130 = +52. The host check (tests/checks/screen.rs, tests/checks.rs) is +100.

The brief's questions

• Is the fix proven for CI's firmware? No, it is only modelled. The edk2 behaviour the model rests on does match upstream GraphicsConsole.c: the mode table at :42-52, centring at :276-323, wrap and then mCrLfString at :1044-1048, and the last-row line feed scrolling at :933-965. CI's own serial also names the mode: nightly 36696295750, job 109873180506, carries ESC[8;056;240t before its last ESC[2J. The PR body does not use that. But this check has never run on Debian OVMF under KVM. Its 240x56 host case is the author's own renderer, and every mutant listed in the PR body fails on the 80x50 case first.
• What a nightly must show: run gh workflow run nightly.yml --ref wt/toyos-loaderlines, with the run's headSha equal to the head being judged. On the shard that runs the test, the log must carry [screen] the panel carries all 41 rows the console put at its edge in its 240x56 text mode, 14 of them after the GOP query and then PASS screen_loader_lines.
  • 41 and 14 are the red nightly's console counted by this model: 41 lines after the last ESC[2J, all under 240 columns and all lit in their first 8 cells, 14 of them after GOP: mode. bootloader/ is unchanged since ace064f9d.
  • Any mode other than 240x56 makes the root-cause table wrong, even on a green run.
• Written or copied? Written by the author from edk2's source. Only the mode table's numbers and the >> 1 centring are verbatim, and those are data. None of edk2's control flow is carried over. No edk2 file or asset enters the tree.
• A second implementation? No. The tree has no edk2 console model and no CSI stripper: git grep '\x1b' in tests/ and src/ finds only src/kernelconsole.rs's fixture, which does a different job. Inside the diff, edk2_panel re-implements wrap and scroll beside TextMode::panel. Both come from one reading of edk2, so they agree on anything that reading got wrong.
• Is the size earned? Yes. The net +52 buys the mode inference and a row model. They replace a band counter that miscounted and a two-boot comparison, and both are deleted.

BLOCKER

• tests/toyos.rs:3637-3639 — the one screendump is taken after the serial line arrives, not after the panel has scrolled. That is a race, and the equality check cannot tolerate it.
  • uefi-services 0.23 println! sends the line feed as its own OutputString("\r\n") (uefi 0.26 output.rs:169-209). edk2 scrolls on that line feed at the last row (GraphicsConsole.c:933-965). At 80x50 the loader's 58 rows scroll, so the last line feed moves every row.
  • wait_for_ready returns on the completed serial line (tests/common/qemu.rs:4783). If ConSplitter writes the terminal before the graphics console, the dump lands before the scroll and every row is one off. Nobody has measured that order.
  • main's range check tolerated this. The PR's own "Unsure" names it, and issues/build/parallel-tests-red-under-other-suites.md:296-348 records this test's panel lagging its marker.
  • To close it, take the dump after an event the guest emits only after the scroll. The kernel's first [kernel record on the 16550 follows ExitBootServices, and the repaint refusal stays. Alternatively, repeat screendump_while until the row maps agree, bounded, and fail with both maps.
• PR body, "Fixes the screen_loader_lines red on main" — this claim has no measurement on the setup that was red: CI's KVM with Debian OVMF in 240x56. It needs the nightly above before The redlist and the recorded durations go: a red test is fixed or deleted with its issue, a flaky test is deleted at once, and shards deal the task list in turn #639 restores the test on it.

NOTE

• tests/checks/screen.rs:124-139 — no staged case in the host check can fail; it only proves agreement. Add a control in both modes: edk2_panel(1920, 1080, staged, &lines[..45]) must differ from mode.panel(lines.iter().copied()).
• tests/toyos.rs:3659-3671 — drawn changes no row on either measured console. The only CSI after the last ESC[2J is the leading cursor-home: 116→126 columns at 240, and 2 rows at 80 either way, scrolled off. Deleting it passes both runs. Delete it, or give it a host input where it decides a row.
• tests/common/screen.rs:287 — TextMode::printed is public only for the success line's "N of them after the GOP query". Fold it into panel and drop that clause.

REMOVE

• PR body ¶1, "PR The redlist and the recorded durations go: a red test is fixed or deleted with its issue, a flaky test is deleted at once, and shards deal the task list in turn #639 … overlaps with this one: land one of the two." — false: The redlist and the recorded durations go: a red test is fixed or deleted with its issue, a flaky test is deleted at once, and shards deal the task list in turn #639 at ee5b14cc4 restores the test on top of this PR.
• PR body, "Independent oracle" — this is the author's own model, not an independent one, and it has no command or log.
• PR body, "Guest runs requested, not run by me" — issuecomment-5916132737 has replaced it.
• PR body, "Unsure" first bullet — the control's own failure message names 80x50.

SEND BACK

[Japabu]

Orchestrator runs at 6e0d7da (logs orch/logs/640r3-*.log):

job	args	exit	line
head	screen_loader_lines	0	[screen] the panel carries all 49 rows the console put at its edge in its 80x50 text mode
exclusive-GOP control	screen_loader_lines + exclusive-gop.patch	1	FAIL screen_loader_lines: the panel's first 8 cells carry 38 rows of text where the console put 49 there in its 80x50 text mode, row by row
whole	(none)	1	test result: FAILED. 501 passed, 1 failed, 0 invalidated, 502 total (324.6s) — the one red is process_stats (exit 101), a filed flake (process-stats-exits-101-beside-other-guests.md) that #639 deletes

Nightly at this head: https://github.com/ToyOSOrg/ToyOS/actions/runs/36763711317 (queued behind 36760010132 at 382919c, whose twelve guest shards all passed).

[Japabu]

Review round 2, head 6e0d7da82. CI host passed at this head: run 36763674229, job 110052319695 (headSha 6e0d7da82). Its log shows checks::firmware_rows_at_the_edge ... ok and [ci] Host: 55 step(s), all green.

Round 1 BLOCKERs

• CLOSED — tests/toyos.rs: one dump raced the last line feed's scroll. The branch now dumps back to back until two dumps agree, which is the option round 1 named. Measured green at this head by the orchestrator (80x50, 49 rows) and by nightly 36763711317, guest (10), job 110093628053 (240x56, 41 rows).
• CLOSED — PR body, "Fixes": the claim had no measurement on CI's firmware. Nightly 36763711317 (headSha 6e0d7da82), job 110093628053, carries [screen] the panel carries all 41 rows the console put at its edge in its 240x56 text mode and then PASS screen_loader_lines (2s).

The brief's questions

• Is the test right? It passes on both edk2 builds it has met. The exclusive-GOP control is red on the dev host at 80x50. At 240x56 the control has run only against the author's host renderer.
  • It still cannot wait on its event. After the last loader line's scroll, the guest emits nothing until the kernel repaints the panel. So "two dumps agree" stands in for the scroll by elapsed time.
  • The guest is never stopped, and the race with the repaint is now two dumps wide instead of one.
  • Both failures come out red, not green. That is a flake source on a test with five recorded reds: issues/build/parallel-tests-red-under-other-suites.md:296-348, and main's nightlies 36550208853 and 36696295750.
• Is its oracle independent? It is independent of the code under test: the loader draws nothing, OVMF draws the panel, and the serial says what OVMF was given.
  • The expectation is not checked independently of its author. TextMode::panel and edk2_panel are one reading of edk2 plus a copy of its mode table. So the host check proves the pixel reader against that reading and cannot catch a misreading of edk2. Only the two runs on real firmware check the reading.
• The ladder. The behaviour is one token: query_gop opens GraphicsOutput with GetProtocol and not with open_protocol_exclusive (bootloader/src/main.rs:377-395).
  • A host test cannot reach it: the host has no UEFI.
  • Metal cannot reach it: no rig reads the panel, and on the T14 loader.log already holds every line the loader prints (bootloader/src/loaderlog.rs:3-4).
  • A guest test reaches it only through a hand model of edk2's console, pixel heuristics, and a race with the repaint.
  • The bottom rung reaches the regression that actually happened (3b17d6a57): the safe open_protocol_exclusive, which is what an agent tidying away an unsafe block reaches for. Refuse it at compile time. The bootloader is already linted with -D warnings on the PR gate (job 110052319695, the two clippy: bootloader steps).
  • Cut the guest test.

Net lines: +292 −129 = +163. Production 0, tests +163. The cut deletes about 150 of main's lines instead.

BLOCKER

• tests/toyos.rs:3748-3832 — delete screen_loader_lines rather than fix it — it is a guest-only check of a one-token decision that compile time reaches. This branch adds +163 lines where the deletion removes them. Delete, along with it:
  • its SCREEN_TESTS entry and that entry's comment (tests/toyos.rs:472-475);
  • tests/common/screen.rs's firmware_text_mode, edge_rows, edge_lit, EFI_GLYPH_*, EDGE_CELLS and TextMode (main's text_row_bands with them);
  • tests/checks.rs:690-693 and tests/checks/screen.rs:100-208;
  • tests/test-durations:322, unless The redlist and the recorded durations go: a red test is fixed or deleted with its issue, a flaky test is deleted at once, and shards deal the task list in turn #639 has deleted the file by then;
  • LOADER_GOP_LINE and its gate entry (src/bootlog.rs:136-138, :662);
  • loaderlog::GOP_AT (bootloader/src/loaderlog.rs:26-28), folded back into main.rs:421's literal;
  • the test's two sightings at issues/build/parallel-tests-red-under-other-suites.md:296-320.
• clippy.toml — make uefi::table::boot::BootServices::open_protocol_exclusive a disallowed-methods entry. Each of the bootloader's ten exclusive opens then carries #[expect(clippy::disallowed_methods, reason = …)]. Show the measurement in the PR body: planting bs.open_protocol_exclusive::<GraphicsOutput>(gop_handle) in query_gop turns cargo run -- --clippy red, with its exit code and log, and green again once it is removed — why: this is the regression 3b17d6a57 fixed and the only one the cut test guarded. Serial still carries every line, so without this every other tier stays green on it.

REMOVE

• tests/toyos.rs:472-474 — "Two boots… a count of rows against a count of lines" — false at this head: the test boots once and compares row maps.
• PR body — every section describes code this verdict deletes, and "Unproven until a nightly shows it" has since been measured. The deletion's body names what goes, the ladder rung that replaces it, and the planted red/green clippy measurement, and nothing else.

SEND BACK

[Japabu]

Closed as superseded: main deleted screen_loader_lines (212516e, in #639), and #660 replaces what it guarded with a compile-time refusal of an exclusive GOP open (clippy.toml bans open_protocol; every open goes through protocol::get). Nothing to carry.