Re: loader_4th.efi broke?

On Fri, 20 May 2022 20:19:58 +0300
Toomas Soome <tsoome@me.com> wrote:

> 
> 
> > On 20. May 2022, at 20:11, Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net> wrote:
> > 
> > On Fri, 20 May 2022, Toomas Soome wrote:
> > 
> >>> On 20. May 2022, at 20:00, Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net> wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> something between
> >>> 	255692.f70de61e567df59bceb2d18c8bc1b54943a7466b and
> >>> 	255723.b3fa36efe797445cb0b4fd26d79226836db2a2b3
> >>> made loader_4th.efi go all
> >>> 	"failed to allocate staging area: 9"
> >>> 
> >>> I am netbooting booting, no ZFS involved.
> >>> One other data point: the base system compile may have changed in that time.
> >>> 
> >>> I haven't dug into yet. Is anyone else seeing this?
> >>> 
> >> 
> >> staging area will be allocated very early, so for some reason either the memory map is fragmented or there is just too low memory.
> >> 
> >> 9 is EFI_OUT_OF_RESOURCES.
> > 
> > The UEFI hasn't changed; 64GB of memory haven't changed. Power
> > cycling didn't make a difference. Going back to the old one
> > immediately worked again. I saw no changes in stand/ relevant.
> > 
> > Is there a way to debug this or should we simply "stop" if this fails
> > rather than endlessly fill the console with it?
> > 
> 
> 
> um, ok 64GB should be plenty;) of course, if the firmware is squashing low memory map to small chunks, then there is problem (we are asking to use low 4GB because of buggy firmwares?), but you can try loader_lua.efi. The other cause could be grown kernel modules - we try to allocate 64MB staging area first, if it is not enough, then we try to get larger chunk?.
> 
> Of course, screen spamming is bug, that should not happen. 
> 
> rgds,
> toomas

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

 It was bisected to the latest llvm update, I haven't digged yet.

-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@FreeBSD.org>