Created attachment 213593 [details] acpi error 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: Author: cem Date: Mon Apr 20 18:01:45 UTC 2020 New revision: 360131 URL: https://svnweb.freebsd.org/changeset/base/360131 Log: 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 of probe. 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 for now. PR: 245757 Changes: head/sys/dev/acpica/acpi_ec.c
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.