On Fri, 20 May 2022 20:19:58 +0300 Toomas Soome <tso...@me.com> wrote:
> > > > On 20. May 2022, at 20:11, Bjoern A. Zeeb <bzeeb-li...@lists.zabbadoz.net> > > wrote: > > > > On Fri, 20 May 2022, Toomas Soome wrote: > > > >>> On 20. May 2022, at 20:00, Bjoern A. Zeeb > >>> <bzeeb-li...@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 <m...@bidouilliste.com> <m...@freebsd.org>
