Bug 196415

Summary:	"cannot release Mutex [PATM]" when resuming
Product:	ACPI	Reporter:	Patrik Kullman (patrik.kullman)
Component:	BIOS	Assignee:	Lv Zheng (lv.zheng)
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	mika.westerberg, pmenzel+bugzilla.kernel.org, rjw, yu.c.chen
Priority:	P1
Hardware:	Intel
OS:	Linux
Kernel Version:	4.13-rc1	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	acpidump -o acpidump

Description Patrik Kullman 2017-07-18 19:46:59 UTC

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)

Comment 1 Chen Yu 2017-07-24 02:11:03 UTC

Hi Patrik,
Please upload the acpidump file. It looks like a BIOS table issue from first glance. Let me add acpi expert Lv.

Comment 2 Patrik Kullman 2017-07-24 20:27:41 UTC

Created attachment 257691 [details]
acpidump -o acpidump

acpidump

Comment 3 Lv Zheng 2017-07-31 06:02:03 UTC

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.

Comment 4 Lv Zheng 2017-07-31 06:03:45 UTC

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.

Comment 5 Patrik Kullman 2017-08-02 12:01:32 UTC

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.

Comment 6 Lv Zheng 2017-08-03 02:54:30 UTC

Then we need to debug, could you check comment 4 and continue?

Comment 7 Rafael J. Wysocki 2017-08-07 20:43:52 UTC

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.

Comment 8 Patrik Kullman 2017-08-07 21:13:24 UTC

This was literally updated during my kernel compile :)

So this bug should be reported where?

Dell for a BIOS update? What's AML ?

Comment 9 Lv Zheng 2017-08-08 02:28:16 UTC

You should have no functional problem with such error.

Comment 10 Rafael J. Wysocki 2017-08-09 00:53:05 UTC

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.

Comment 11 Lv Zheng 2017-08-09 01:27:50 UTC


*** This bug has been marked as a duplicate of bug 194031 ***