Date: Fri, 20 May 2022 19:33:34 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: Toomas Soome <tsoome@me.com> Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, current@freebsd.org Subject: Re: loader_4th.efi broke? Message-ID: <20220520193334.2a791540c8eefaf73d0173fe@bidouilliste.com> In-Reply-To: <1BA529E5-064B-46A8-A412-3D7A66AD6D2F@me.com> References: <alpine.BSF.2.00.2205201651000.68830@ai.fobar.qr> <71D61E79-B3A5-49FA-9B9E-26E124A5B4EF@me.com> <alpine.BSF.2.00.2205201709360.68830@ai.fobar.qr> <1BA529E5-064B-46A8-A412-3D7A66AD6D2F@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 May 2022 20:19:58 +0300 Toomas Soome <tsoome@me.com> wrote: >=20 >=20 > > On 20. May 2022, at 20:11, Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.n= et> wrote: > >=20 > > On Fri, 20 May 2022, Toomas Soome wrote: > >=20 > >>> On 20. May 2022, at 20:00, Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz= .net> wrote: > >>>=20 > >>> Hi, > >>>=20 > >>> something between > >>> 255692.f70de61e567df59bceb2d18c8bc1b54943a7466b and > >>> 255723.b3fa36efe797445cb0b4fd26d79226836db2a2b3 > >>> made loader_4th.efi go all > >>> "failed to allocate staging area: 9" > >>>=20 > >>> I am netbooting booting, no ZFS involved. > >>> One other data point: the base system compile may have changed in tha= t time. > >>>=20 > >>> I haven't dug into yet. Is anyone else seeing this? > >>>=20 > >>=20 > >> staging area will be allocated very early, so for some reason either t= he memory map is fragmented or there is just too low memory. > >>=20 > >> 9 is EFI_OUT_OF_RESOURCES. > >=20 > > 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. > >=20 > > Is there a way to debug this or should we simply "stop" if this fails > > rather than endlessly fill the console with it? > >=20 >=20 >=20 > um, ok 64GB should be plenty;) of course, if the firmware is squashing lo= w memory map to small chunks, then there is problem (we are asking to use l= ow 4GB because of buggy firmwares?), but you can try loader_lua.efi. The ot= her cause could be grown kernel modules - we try to allocate 64MB staging a= rea first, if it is not enough, then we try to get larger chunk?. >=20 > Of course, screen spamming is bug, that should not happen.=20 >=20 > rgds, > toomas See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264021 It was bisected to the latest llvm update, I haven't digged yet. --=20 Emmanuel Vadot <manu@bidouilliste.com> <manu@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220520193334.2a791540c8eefaf73d0173fe>