Date: Mon, 15 Jun 2026 05:12:02 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 294406] Dell Inspiron 14 7445 2-in-1 crashing - AMD Ryzen 7 8840HS Message-ID: <bug-294406-227-tTYttOzr4S@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-294406-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294406 --- Comment #18 from Anthony Katernoza <anthony.katernoza@gmail.com> --- (In reply to Anthony Katernoza from comment #16) I was able to compile SSDT and DSDT records using acpidump -o, along with other .dsl records that log low level computer activity. There were a few issues related to what I think is an inability to traverse XSDT records, but I was able to get around the issues once, during troubleshooting. I haven’t been able to get the logs since, however. These logs are attached in a 7zip file. Additionally, I was able to remove kernel panics on my multiuser system completely, by disabling my rtw890 wifi card. Before then, it got to a point of panicking every few minutes. The system as of now still has significant keyboard latency. While doing some troubleshooting with the acpidump files as well as some acpiconf, sysctl, dmesg and devinfo troubleshooting on my own, I discovered a few things: Starting with the most straightforward results, sysctl hw.acpi.supported_sleep_state has only S4 and S5 as supported sleep states. It does not have any supported S0 and S0ix states. Additionally a sysctl of dev.acpi doesn’t list _CRT/Critical and _TMP/Temperature nodes at all. AMDGPIO isn’t attaching. The system is operating solely on the legacy keyboard emulator. I have done things like modifying loader.conf to load acpi_wmi, acpi_video and wmt, and have also put hints to load amdgpio at acpi, set amdgpio.0.disabled to 0, and disable the legacy emulator. These attempts to force it to load didn’t work. Devinfo -v also shows that gpio0 is connected to AMDI0030, but that its GPIO character device (gpioc0) has an UNKNOWN handle. I have tried to disable generic event devices in loader.conf and attempted to set Osname and install_interface to different versions of Windows, but this also didn’t work. Furthermore, devinfo -v has no mention of a %location parameter for the GPIO controller. Doing a less search of devinfo -v for wmi says that “_HID=PNP0C14”, “_UID=0”, “_CID=none at handle=\AOD_”. Sysctl dev.acpi_wmi.0 only yields IOMMU, parent, pnpinfo, location, driver and desc. This is despite the laptop being a 2-in-1 that has hardware that should attach to AOD and that devinfo has it present. Attempts to specifically force ACPI to evaluate AOD, ie. hw.acpi.reset_video=”1”, also didn’t change this situation. I also attempted a debug.acpi.resume_beep=”1”, which provided no further information or “beeps”. An important additional detail is a device called gpio_aei0. This device is on pins 0, 54, 58, 59, 61, 62. It is listed as an unknown device in a verbose version of dmesg. In the same vein, gpioc0 (under gpiobus0) is listed as "handle=unknown". Below the AEI0 line, UTK0001, AMDI0052/I0020/I0053 are considered "unknown pnpinfo". A check of dmesg -v confirmed that the controller logic, is also not even being touched, as it doesn't appear in the logs. Moving onto the SSDT/DSDT searches, I looked for information in the OSI sections of DSDT and SSDT. Interestingly, I saw that above the logic for the windows version, there was logic saying "M047=Zero" and "M460 ("...this OS cannot support DisplayMux\n…", in ssdt8.dsl file. This is all part of a “Method (M045, 0, Serialized)” logic block that handles “CondRendOf (_OSI))” logic. AEI and GPIO._AEI appear in ssdt19.dsl, referring to it for M460 ("OEM-ASL\\_SB.GPIO._AEI\n" with a Return line for BUF0 as \_SB_.GPIO._AEI.BUF0 */ . In terms of other connections to devinfo, dsdt.dsl has some more logs about UTK0001, defining it as a UART Serial device under Scope _SB.FUR0, which also doesn't appear in dmesg at all, nor does it list UART info. At least in my understanding, what this looks to me is that parts of my keyboard logic via Sensor Fusion Hub and some associated AMD MP2 logic aren't being loaded. Without these parts of the AMD Architecture being satisfied, the system then doesn't assign the modern keyboard drivers to my built-in keyboard and instead assigns a legacy emulator with significant latency. I bring focus to these things because of the fact that there is no UART activity on my PCI bus at the same time devices under 0x14ec (the dummy functions in pciconf, but this may be an AMD MP2 Bridge in a dummy state) and IPU/DASP systems aren't functioning. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-294406-227-tTYttOzr4S>