Created attachment 213593 [details]
Look this attachment image.
OS: FreeBSD 13.0-CURRENT 20200416 AMD64
CPU: AMD Ryzen 3700U
LAPTOP: DELL 5585
I'm *guessing* your firmware is attempting to "reopen" the existing object to add _GPE methods, and those "already exists" messages prevent the reopen and result in the acpi_ec0 errors.
Still, acpi_ec_attach shouldn't panic even if it cannot attach. It might be possible to blacklist the acpi_ec driver as a short-term workaround via 'debug.acpi.disabled="ec"' in loader.conf or at the loader command line. I don't know what the ec driver does or if it is crucial for anything else.
If you can get the system to boot that way, please 'acpidump -dt' and attach the result (maybe compressed if it is large).
A commit references this bug:
Date: Mon Apr 20 18:01:45 UTC 2020
New revision: 360131
acpi_ec(4): Do not probe "successfully" if an error occurred
All of the 'goto out;' cases in this probe routine without explicit
initialization of 'ret' indicate error cases and were clearly intended
to use the initial definition of 'ret' with ENXIO. However, 'ret' was
accidentally squashed by reuse for a subroutine call near the beginning
Use a different variable for the subroutine status to preserve ENXIO ret
for the 'goto out's as a minimal solution to the panic reported at attach
I believe r360131 (this bug's commit) breaks the battery status and backlight hotkeys on the HP Spectre x360 13-ap0053dx.
This is discussed more in Bug 245778.