I get this when resuming from s2idle, why? [14185.214899] PM: resume from suspend-to-idle [14185.278817] PM: early resume of devices complete after 61.545 msecs [14185.451011] PM: resume of devices complete after 172.191 msecs [14185.451486] PM: Finishing wakeup. [14185.451488] OOM killer enabled. [14185.451489] Restarting tasks ... [14185.485482] [drm] RC6 on [14185.494273] done. [14185.567532] thermal thermal_zone11: failed to read out thermal zone (-5) [14185.608389] IPv6: ADDRCONF(NETDEV_UP): wlp60s0: link is not ready [14185.649187] ACPI Error: Thread 1737830144 cannot release Mutex [PATM] acquired by thread 1784289152 (20170531/exmutex-416) [14185.649203] ACPI Error: Method parse/execution failed \_SB.PCI0.LPCB.ECDV._Q66, AE_AML_NOT_OWNER (20170531/psparse-550)
Hi Patrik, Please upload the acpidump file. It looks like a BIOS table issue from first glance. Let me add acpi expert Lv.
Created attachment 257691 [details] acpidump -o acpidump acpidump
If the table was correct and wasn't customized, decoded _Q66 is as follows: Method (_Q66, 0, NotSerialized) // _Qxx: EC Query { Acquire (PATM, 0x0064) If ((ECRD == One)) { NEVT () } Release (PATM) Return (Zero) } Again if the table was correct, it looks the mutex mechanism failed to work properly throughout suspend/resume process. Then this looks not a BIOS table issue.
Please also upload full dmesg output containing this problematic suspend/resume process and boot with acpi.trace_state=enable here. You need to configure CONFIG_ACPI_DEBUG and recompile the kernel.
I have not done something else than acpidump with the table - how can it be customized? Will try to get a hold of an acpi debug kernel, have prepared with the boot parameter.
Then we need to debug, could you check comment 4 and continue?
This evidently is an AML bug. The code quoted in comment #3 uses Acquire() with a timeout, but it doesn't check the return value and invokes Release() even if the mutex wasn't actually acquired due to the timeout. That invocation of Release() is what ACPICA is complaining about with quite arguably is correct. Thanks to Mika for input here and closing as invalid.
This was literally updated during my kernel compile :) So this bug should be reported where? Dell for a BIOS update? What's AML ?
You should have no functional problem with such error.
On Monday, August 7, 2017 11:13:24 PM CEST bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=196415 > > --- Comment #8 from Patrik Kullman (patrik.kullman@gmail.com) --- > This was literally updated during my kernel compile :) > > So this bug should be reported where? > > Dell for a BIOS update? What's AML ? The code provided by the firmware to be executed by the kernel. IOW, firmware issue, so yes, Dell for BIOS update.
*** This bug has been marked as a duplicate of bug 194031 ***