Re: Recent current panic
- In reply to: Ahmad Khalifa : "Re: Recent current panic"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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>