On Sat, 6 Jun 2026, Warner Losh wrote:
The branch main has been updated by imp:
URL:
https://cgit.FreeBSD.org/src/commit/?id=3915ffb1c3e04b26d1506bf35d3f665b2e25a915
commit 3915ffb1c3e04b26d1506bf35d3f665b2e25a915
Author: Warner Losh <[email protected]>
AuthorDate: 2026-06-05 05:18:40 +0000
Commit: Warner Losh <[email protected]>
CommitDate: 2026-06-06 01:24:42 +0000
loader.efi: Fix when staging moves late
Prior to this commit, we'd compute the page tables and have the last
entries point to the staging area. We'd then add some more metadata to
the image and boot. This assumed the staging area didn't need to move
for this last bit of data.
However, if we go over the staging limit, when we copyin new data, we
grow the staging area, usually be moving it to a lower address. This
overage usually happens when we're loading modules and so things work
out nicely. Sometimes we're close to the limit, and we need to do this
growing inside bi_load, after we've computed the page table, making the
page table wrong, and the code we jump to random rather than the btext
routine we normally start at.
To fix this, move computation of the table (but not its allocation) to
after bi_load, but before we call the trampoline.
This problem was most observed when loading microcode for many peole,
but Gleb reproduced the error with a set of modules that didn't include
ucode.
I looked through the PR (not all of it) and I have seen little explanations
of how this bug was observed as a user, as in how far did the boot process get
(possibly with beasty disabled).
The reason I am asking is that I am wondering if the various occasions where
people in the last years have seen "Booting [/boot/kernel/kernel]...", possibly
"Loading splash ok" but never saw the boot marker "---<<BOOT>>---" (or any
things in between) anymore could have been the same bug?
PR: 294630
Reviewed by: kib (prior version)
Sponsored by: Netflix
MFC After: insta per re@ request
Differential Revision: https://reviews.freebsd.org/D57462
--
Bjoern A. Zeeb r15:7
