[Bug 264021] efi: failed to allocate staging area: 9

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264021

Mark Millard <marklmi26-fbsd@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marklmi26-fbsd@yahoo.com

--- Comment #9 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
Just FYI: My report at

https://lists.freebsd.org/archives/freebsd-arm/2022-May/001354.html

possibly is the same sort of issue. Both aarch64 and armv7 systems
had the system-llvm14 based build of loader.efi crash very early
in the boot. I reverted just the loader.efi copies that predated
my progressing to the system llvm14 basis (so, back to late April)
and that made things work.

But amd64's update via the same source tree contents did not have
problems using its llvm14 based loader.efi. (No other FreeBSD
platforms around to try.) So I've only evidence for armv7 and
aarch64 problems.

I'll note that the aarch64 context uses an EDK2 based UEFI/ACPI
and the armv7 context uses a U-Boot 2022.04 based UEFI (not ACPI).
Both have been in use for some time before this upgrade activity
and were not changed.

My installed contexts are from non-debug builworld buildkernel
based builds, despite booting main [so: 14]. I could install
debug kernels and see what they report if I also put back the
loader.efi copies built via llvm14. Right now that does not
look to be likely to be useful.

For reference for the failure contexts:

aarch64: MACCHIATObin Double Shot
armv7:   Orange Pi+ 2ed

I have access to more aarch64 contexts and a RPi2 v1.1 (armv7).
But I avoided upgrading the loader.efi copies on any boot media
for either type after the first one of each type got the boot
failures --and I reverted on the media that showed the failure
for each type.

-- 
You are receiving this mail because:
You are the assignee for the bug.