From nobody Mon Jun 15 05:12:02 2026 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4gdysZ308gz6gnj9 for ; Mon, 15 Jun 2026 05:12:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R13" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gdysZ2D97z3Wvf for ; Mon, 15 Jun 2026 05:12:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1781500322; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PksK64TdOSe5/xfMKvy5cIuFtftbfhPvLA0UAiEdN6Y=; b=dKF/sYMnIxpQbRFRG5XjmypqGIpVtjEZGlIFV48I9uBz766Jr8RJLyJ2a74NQMvxqVn4iR AIeKvrssiG7l+shaaPLBdg2zKPYmimzRnoiKn7kfnzQjCsGiRWPyaCOlPAEYtv/7hpjlIS jViSBGw7BUHBaoNDOXKGJrLLSltBuoJ0ZbNKIRcliXhfZKbz84PC8DTcm/L9LNGKurSf3W 2bMIVFtK/GbiKjQ56rgQzwM1kV40v3QQcF4/mC6b6NHDms+M5FhRWqpZsinFVAQDQxFra8 j3B3yOXhHSkMzU8AyH66YthVzrdFC6uE9i0mwt0tvH7lDswz9SopIrZKKuQdfg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1781500322; a=rsa-sha256; cv=none; b=K2NF9SHTB2jc5vH48O3vFU4+2nK3kxY4AzU/JctAo07kJTm9gjt8AY6bgvOmSAgKNEqs4v +yJj1ODwdnA6WABDe7NoUngOyDFsy1b07MRGeAfPxXsRmJTEHB0R9gx7uqDpX3kZlFm+Kr t8LsuP2z+ztd1PLGUjWiwKPHJ2Cl311xcJa3tp1Enypgvf5egdcuIPtNbE3PFp3ZoJZjEQ KDeh5N1QWMiar27d+V6tEzgQoT8sO5dR3xy/8B6GTLiqIJXyV3iKQEaFMH6WLNjq5YUpHw 8ysLtea/XqW0FPLwJ1DwLKL5UT8j5eninzaf2aSzsN1oatjt4Inn1z54tjf/1A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1781500322; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PksK64TdOSe5/xfMKvy5cIuFtftbfhPvLA0UAiEdN6Y=; b=f/FhFTVz0AzBn+wRgluuhC32a68fDlHe0mfL+7SXsxgFDBchQYax8TCs1CcPvxst2ixQ9L 78mcnUH3bk6Ce/OYiPc/8lZQtMgvw5omy9yaHaepXdqkhg8x1JwBWtsBWRw2M0k4ht2mYC 8xNe3BR423v7v9Hi8w3iYiSXU18orQ1V8DtOQ9/pSEFgurWO9NGRZg6aZcFcKPcgklA1kX CL9TFHjPrFQP4nxx4cTU8JtBdA6GD0XkP6H6N0iytL3wyuns5VzEerpFatn3kWYTykYroq /1CIHTX0wg/Ug0kfoBantcYj3fK3x6kZrnAQg8sYh9cCF7+NiTBeoFk9A5BcJQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4gdysZ1mb8zj0d for ; Mon, 15 Jun 2026 05:12:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 65F5C2b8088488 for ; Mon, 15 Jun 2026 05:12:02 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 65F5C2aU088487 for bugs@FreeBSD.org; Mon, 15 Jun 2026 05:12:02 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 294406] Dell Inspiron 14 7445 2-in-1 crashing - AMD Ryzen 7 8840HS Date: Mon, 15 Jun 2026 05:12:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 15.0-RELEASE X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: anthony.katernoza@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D294406 --- Comment #18 from Anthony Katernoza --- (In reply to Anthony Katernoza from comment #16) I was able to compile SSDT and DSDT records using acpidump -o, along with o= ther .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=E2=80= =99t 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 poin= t 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=E2=80=99t list _CRT/Critical and _TMP/Temperature nodes at a= ll. AMDGPIO isn=E2=80=99t attaching. The system is operating solely on the lega= cy 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=E2=80=99t 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=E2= =80=99t 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 =E2=80=9C_HID=3DPNP0C14= =E2=80=9D, =E2=80=9C_UID=3D0=E2=80=9D, =E2=80=9C_CID=3Dnone at handle=3D\AOD_=E2=80=9D. 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=3D=E2=80=9D1=E2=80=9D, also didn=E2=80=99t change this = situation. I also attempted a debug.acpi.resume_beep=3D=E2=80=9D1=E2=80=9D, which provided no further inf= ormation or =E2=80=9Cbeeps=E2=80=9D. 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=3Dunknown". Below the AEI0 line, UTK0001, AMDI0052/I0020/I0053 are considered "unknown pnpinfo". A check of dmesg -v confirmed that the contro= ller 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=3DZero" and "M460 ("...this OS cannot support DisplayMux\n=E2=80=A6", in ssdt8.dsl file. This is all part = of a =E2=80=9CMethod (M045, 0, Serialized)=E2=80=9D logic block that handles =E2=80=9CCondRendOf= (_OSI))=E2=80=9D 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, wh= ich 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 keybo= ard and instead assigns a legacy emulator with significant latency. I bring foc= us 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. --=20 You are receiving this mail because: You are the assignee for the bug.=