Bug 211737

Summary:	"1 arguments were passed to a non-method ACPI object" kernel log spam - Lenovo ThinkPad L570
Product:	ACPI	Reporter:	jaak+bugzilla.kernel.org
Component:	ACPICA-Core	Assignee:	Zhang Rui (rui.zhang)
Status:	CLOSED DOCUMENTED
Severity:	normal	CC:	erik.kaneda, rui.zhang
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	5.10.16	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	dmesg output of acpidump output of acpidump --binary

Description jaak+bugzilla.kernel.org 2021-02-14 14:27:26 UTC

On a Lenovo ThinkPad L570, the Linux kernel completely fills its log with a single message, e.g.:

[  213.938902] ACPI: \_SB.PCI0.LPCB.EC.ECRD: 1 arguments were passed to a non-method ACPI object (RegionField) (20200925/nsarguments-206)
[  213.938910] ACPI: \_SB.PCI0.LPCB.EC.ECRD: 1 arguments were passed to a non-method ACPI object (RegionField) (20200925/nsarguments-206)
[  213.938924] ACPI: \_SB.PCI0.LPCB.EC.ECRD: 1 arguments were passed to a non-method ACPI object (RegionField) (20200925/nsarguments-206)
[  213.938933] ACPI: \_SB.PCI0.LPCB.EC.ECRD: 1 arguments were passed to a non-method ACPI object (RegionField) (20200925/nsarguments-206)
[  213.938940] ACPI: \_SB.PCI0.LPCB.EC.ECRD: 1 arguments were passed to a non-method ACPI object (RegionField) (20200925/nsarguments-206)
[  213.938948] ACPI: \_SB.PCI0.LPCB.EC.ECRD: 1 arguments were passed to a non-method ACPI object (RegionField) (20200925/nsarguments-206)

Note that these are very frequent. By the time I was able to login, these messages had already pushed out everything else from `dmesg` output.

I suspect this has been happening for a long time with older kernels as well, and due to the logs ending up on disk, has also been very detrimental to the SSD drives.

Comment 1 Zhang Rui 2021-03-04 05:28:59 UTC

please attach the acpidump output of this machine.
please attach the dmesg output after boot.

Can you boot into some older kernel and check if the problem still exists?

Comment 2 jaak+bugzilla.kernel.org 2021-03-04 07:43:01 UTC

Created attachment 295629 [details]
dmesg

Here is the output of dmesg.
I'd have to recompile the kernel to get /dev/mem support required for acpidump.

Comment 3 jaak+bugzilla.kernel.org 2021-03-04 08:09:37 UTC

Created attachment 295633 [details]
output of acpidump

Comment 4 jaak+bugzilla.kernel.org 2021-03-04 08:10:25 UTC

Created attachment 295635 [details]
output of acpidump --binary

Comment 5 jaak+bugzilla.kernel.org 2021-03-04 08:59:53 UTC

This also seems to happen with vanilla sources for Linux kernel versions 4.19.117, 4.14.222, 4.9.258 and 4.4.258, so it seems reasonable to assume that this has been an issue since at least 4.4.

Comment 6 Zhang Rui 2021-03-04 13:53:54 UTC

$ grep ECRD *.dsl
dsdt.dsl:            ECRD,   1, 
dsdt.dsl:                \_SB.PCI0.LPCB.EC.ECRD = 0x01
dsdt.dsl:                \_SB.PCI0.LPCB.EC.ECRD = 0x00
ssdt2.dsl:    External (_SB_.PCI0.LPCB.H_EC.ECRD, MethodObj)    // 1 Arguments
ssdt2.dsl:                    RPMV [0x02] = \_SB.PCI0.LPCB.H_EC.ECRD (RefOf (\_SB.PCI0.LPCB.H_EC.CFSP))

$ grep FSDD *.dsl
ssdt2.dsl:            Method (FSDD, 0, NotSerialized)

First of all, this is a BIOS bug because ECRD is not defined as a method anywhere, but it is referenced as an ACPI method in ssdt2.


To me, the thing I don't understand is that why this error is triggered frequently.
The bogus AML code is in ACPI method FSDD, and FSDD method is not invoked by another other method, or by Linux kernel.
Erik, any ideas?

Comment 7 Zhang Rui 2021-05-31 01:55:46 UTC

@jaak+bugzilla.kernel.org@ristioja.ee

Do you observe any functionality issue?
As I said early, this is a BIOS bug. Please check if there is any new BIOS release or not. If yes, please check if the problem can be fixed by a BIOS upgrade.

There is nothing we can do from kernel space to get this resolved.