Re: Recent current panic

From: Guido Falsi <mad_at_madpilot.net>
Date: Wed, 08 Jul 2026 06:49:57 UTC
On 7/7/26 22:57, Ahmad Khalifa wrote:
> On Tue Jul 7, 2026 at 11:29 PM +0300, Guido Falsi wrote:
>> On 7/7/26 22:18, Kyle Evans wrote:
>>> On 7/7/26 15:11, Guido Falsi wrote:
>>>> On 7/7/26 21:54, Kyle Evans wrote:
>>>
>>> Does `efivar -l` also cause a fault?  Sometimes firmware does stupid
>>> things like require regions we wouldn't normally have mapped to
>>> operate.  Ahmad (CC'd) had a change to map the first page because of
>>> firmware shenanigans in 4add1a7a46b5cb, this might be exactly the case
>>> here.  I think they had found other type-based shenanigans as well.
>>>
>>
>> `efivar -l` did not trigger any further EFI fault.
> 
> Hmm, it's odd that it's faulting on address 0. IIRC that should always
> be mapped after 4add1a7a46b5cb (as Kyle mentioned).
> 
> Could you send the output of sysctl machdep.efi_map please? I'm starting
> to build somewhat of a collection of those. :)

Sure, attaching it.

> 
> If you need the functionality the fault is preventing, you could also
> have a look at https://cgit.freebsd.org/src/commit/?id=85dcdb7aad854
> (beware that this would actually eat into the available memory of the
> system.)

I posted about these failures because the second panic was an hard crash 
and was preventing me from completing builds of arm64 NanoBSD images. I 
reported both because I suspected they could be related.

Now I know this first error is unrelated. In fact, I use this machine 
for building world, poudriere and other builds, and is headless 99% of 
the time, so this erro could have gone unnoticed for some time and has 
no ill effects on the machine usage.


> 
> Otherwise the fault should be harmless.
> 

Yes I guess this is correct for this EFI error.

> Thanks.

Thanks to you!

-- 
Guido Falsi <mad@madpilot.net>