Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 May 2022 17:11:23 +0000 (UTC)
From:      "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
To:        Toomas Soome <tsoome@me.com>
Cc:        current@freebsd.org
Subject:   Re: loader_4th.efi broke?
Message-ID:  <alpine.BSF.2.00.2205201709360.68830@ai.fobar.qr>
In-Reply-To: <71D61E79-B3A5-49FA-9B9E-26E124A5B4EF@me.com>
References:  <alpine.BSF.2.00.2205201651000.68830@ai.fobar.qr> <71D61E79-B3A5-49FA-9B9E-26E124A5B4EF@me.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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?

/bz

-- 
Bjoern A. Zeeb                                                     r15:7



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.2205201709360.68830>