Re: loader_4th.efi broke?

> 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