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.
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?
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.
Created attachment 295633 [details] output of acpidump
Created attachment 295635 [details] output of acpidump --binary
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.
$ 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?
@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.