Created attachment 300611 [details] acpidump output text file I have a recently bought Dell Inspiron 15 Plus 7510 Laptop with latest firmware update that has several error messages regarding ACPI in `dmesg`. Firmware Version: ``` DMI: Dell Inc. Inspiron 15 7510/0GNCM6, BIOS 1.4.0 12/10/2021 ``` Errors: ``` Mar 23 18:38:30 arch kernel: ACPI Error: Thread 1150494336 cannot release Mutex [ECMX] acquired by thread 1090374912 (20210930/exmutex-378) Mar 23 18:38:30 arch kernel: ACPI Error: Aborting method \_SB.PC00.LPCB.ECDV._Q66 due to previous error (AE_AML_NOT_OWNER) (20210930/psparse-529) Mar 23 18:38:30 arch kernel: ACPI Warning: \_SB.PC00.PEG1.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20210930/nsarguments-61) Mar 23 18:38:30 arch kernel: ACPI Warning: \_SB.NPCF._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20210930/nsarguments-61) Mar 23 18:38:30 arch kernel: acpi PNP0C14:01: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00) Mar 23 18:38:30 arch kernel: wmi_bus wmi_bus-PNP0C14:02: WQBC data block query control method not found Mar 23 18:38:30 arch kernel: acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00) Mar 23 18:38:30 arch kernel: ACPI BIOS Error (bug): Could not resolve symbol [\S4CT], AE_NOT_FOUND (20210930/psargs-330) Mar 23 18:38:30 arch kernel: ACPI Error: Aborting method \_SB.PC00.LPCB.ECDV.NGFF._CRT due to previous error (AE_NOT_FOUND) (20210930/psparse-529) Mar 23 18:38:30 arch kernel: ACPI BIOS Error (bug): Could not resolve symbol [\S4HT], AE_NOT_FOUND (20210930/psargs-330) Mar 23 18:38:30 arch kernel: ACPI Error: Aborting method \_SB.PC00.LPCB.ECDV.NGFF._HOT due to previous error (AE_NOT_FOUND) (20210930/psparse-529) Mar 23 18:38:30 arch kernel: ACPI BIOS Error (bug): Could not resolve symbol [\S4PT], AE_NOT_FOUND (20210930/psargs-330) Mar 23 18:38:30 arch kernel: ACPI Error: Aborting method \_SB.PC00.LPCB.ECDV.NGFF._PSV due to previous error (AE_NOT_FOUND) (20210930/psparse-529) Mar 23 18:38:30 arch kernel: ACPI BIOS Error (bug): Could not resolve symbol [\S4AT], AE_NOT_FOUND (20210930/psargs-330) Mar 23 18:38:30 arch kernel: ACPI Error: Aborting method \_SB.PC00.LPCB.ECDV.NGFF._AC0 due to previous error (AE_NOT_FOUND) (20210930/psparse-529) Mar 23 18:38:30 arch kernel: acpi PNP0C14:03: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00) Mar 23 18:38:30 arch kernel: acpi PNP0C14:04: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00) Mar 23 18:38:30 arch kernel: acpi PNP0C14:05: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00) Mar 23 18:38:30 arch kernel: acpi PNP0C14:06: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00) Mar 23 18:38:30 arch kernel: acpi PNP0C14:07: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00) ``` The above messages are in the order as they occur in the output. I haven't noticed any critical crash despite these errors in the last 48 hours (installed Linux for the first time on this specific hardware). I tried playing with the `acpi_osi` string just in case, since my old laptop needed that, but that doesn't help. Reporting this here because same errors occur on Fedora as well as Arch. This could be a firmware issue, but I am not sure. I tried calling Dell's Support and they outright declined providing any support because of "Linux". Let me know if any additional info is needed. I have attached the `acpidump` output.
please attach the full dmesg output.
Created attachment 301284 [details] dmesg log full dmesg output attachment as requested at 2022-06-27 03:11:27 UTC by Zhang Rui.
I should also mention that I have already tried a manually-compiled kernel and saw similar logs present in the dmesg output. The issue persists even with the latest firmware/BIOS update for the device released on 2nd of June'22 — v1.8.0.
I don't see the ACPI Error: Thread 1150494336 cannot release Mutex [ECMX] acquired by thread 1090374912 (20210930/exmutex-378) in the dmesg file attached, so the error occurs at runtime, right?
can you attach the full dmesg output that contains the runtime errors?
Created attachment 301292 [details] dmesg log another full dmesg log that shows the Mutex error
(In reply to Zhang Rui from comment #5) > can you attach the full dmesg output that contains the runtime errors? I don't understand. Is a runtime capture different than just dumping the dmesg output or using `journalctl -k`? The file I just uploaded does contain the log showing some problem with a Mutex lock.
this is straight firmware issue, the vendor is not being able to be resolved from ACPI, and when it tries to release the mutex, the thread is not identified as owner, even when the device is the same (get's duplicated in ACPI, god knows why), so the system tries to have 2 different instances of the same device while there were some operations running in the background in one of those, getting a lost connection in the middle of it, and hanging that AML code execution, then the newer instance (thread) of the device in the acpi tries to release the mutex but is not able to, as it is not the owner, something is hiccuping the device while starting over, and leaving behind some unfinished operations, the device gets referenced twice and not able to perform operations in that AML code.