Created attachment 274165 [details]
minimal test case that also exhibits thesame acpi error

I've attached a test case here. What happened was that this passed through the compiler due to a method being declared as an external of an unknown type.

Method (_PDC, 1, NotSerialized)  // _PDC: Processor Driver Capabilities
{
    \_PR.CPU0._PPC = CPPC /* \_PR_.CPPC */
    Local0 = CPDC (Arg0)
    GCAP (Local0)
    Return (Local0)
}

The issue with this _PDC method is the assignment on the first line. _PPC is declared as an external as an unknown type and CPPC is an integer. When all names are loaded in AML namespace, it is known that _PPC is a method that returns a reference...

Could you post the dmesg for the 4.9 kernel? This can tell us the ACPICA version number.

Created attachment 274177 [details]
DMESG 4.9

Here it is dmesg from 4.9 series. `ACPI: Core revision 20160831`.

Created attachment 274179 [details]
Lenovo ThinkPad T450s-asl-dmi-demesg-logs

User Th3Z0ne from Manjaro Forum shared logs. His reply:
```
Hello!
Same happens on a Lenovo T450s:
```
Feb 15 06:51:40 hk-01 kernel: Error parsing PCC subspaces from PCCT
...
Feb 15 06:51:40 hk-01 kernel: ACPI Error: Needed type [Reference], found [Integer] 000000002c22b965 (20170831/exresop-103)
Feb 15 06:51:40 hk-01 kernel: ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [Store] (20170831/dswexec-461)
Feb 15 06:51:40 hk-01 kernel: ACPI Error: Method parse/execution failed \_PR.CPU0._PDC, AE_AML_OPERAND_TYPE (20170831/psparse-550)
```
I was told that is due to an "old" bios/uefi despite having the very latest (actually later than whats on the website as they pulled it due to meltdown/spectre patch trouble) ^^
```

DMI Details:

System Information
	Manufacturer: LENOVO
	Product Name: 20BWS03F00
	Version: ThinkPad T450s
	Serial Number: PC03KM01
	UUID: C7277481-54FA-11CB-BB45-E375A104B5B5
	Wake-up Type: Power Switch
	SKU Number: LENOVO_MT_20BW_BU_Think_FM_ThinkPad T450s
	Family: ThinkPad T450s

Regards

@Erik Schmauss I found bug report about >> AE_AML_OPERAND_TYPE << in RedHat bug tracker about Linux 4.11.3 (ACPI Core Revision: 20170119) reported 2017-06-06:

See: https://bugzilla.redhat.com/show_bug.cgi?id=1459317
--------------------------------------------------------
Gianfranco Cecconi 2017-06-06 15:08:45 EDT

Description of problem:

Since kernel 4.11.3-200 I am getting errors at boot just after grub as described below.

How reproducible:

Fully reproducible at every boot.


Steps to Reproduce:
1. Just boot Fedora

Actual results:

After selecting the latest kernel on Grub, I get the following:

[some timestamp] ACPI Error: Needed type [Reference], found [Integer] ffff9915c5701168 (20170119/exresop-103)
[some timestamp] ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20170119/dswexec-461)
[some timestamp] ACPI Error: Method parse/execution failed [\_PR.CPU0._PDC] (Mode ffff9915c90eb780), AE_AML_OPERAND_TYPE (20170119/psparse-543)

Expected results:

I'd expect no errors nor warnings.

Additional info:

I am also experiencing this issue at the same stage in the boot process https://bugzilla.redhat.com/show_bug.cgi?id=1435837 but it is precedent and has been around since March 2017 without resolution. My guess is that the two issues are not related.

--------------------------------------------------------

4.11.3 Shortlog and PATCH DIFF: https://lkml.org/lkml/2017/5/25/493
4.11.3 Official Changelog https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.11.3

Thanks for all of the information. Here's what's going on: we have confirmed that executing ASL/AML code like the one I've listed in comment #1 results in an error on windows. Also, we have confirmed that we were allowing this code to execute without error in older versions (20160831) but we have made this into an error in more recent versions to match the behavior on windows. Basically, this is a firmware issue...

So from our perspective, the two possible next steps are to contact the firmware vendor to correct the firmware or check to see if there are updates for this firmware

According to intel kernel developer your hardware is buggy unless is not from intel and latest model with latest acpi compiler. So long as intel is developing the kernel, many bugs are not fixed. Disabling acpi errors is the solution:

--- a/include/acpi/platform/acenv.h	(date 1512400986000)
+++ b/include/acpi/platform/acenv.h	(date 1512400986000)
@@ -107,7 +107,7 @@
 #ifdef ACPI_HELP_APP
 #define ACPI_NO_ERROR_MESSAGES
 #endif
-
+#define ACPI_NO_ERROR_MESSAGES
 /* acpi_names configuration. Debug output enabled. */
 
 #ifdef ACPI_NAMES_APP

WORKAROUND
Edit /etc/default/grub and add in GRUB_CMDLINE_LINUX_DEFAULT line AFTER quiet word these: 

vga=current loglevel=3 rd.systemd.show_status=auto rd.udev.log_priority=3

Next update grub : sudo update-grub.

Last thing is creating SYSCTL rule:

sudo bash -c "echo ‘kernel.printk = 3 3 3 3’ > /etc/sysctl.d/20-quiet-printk.conf’"

and reboot. This will just HIDE error msgs during boot, still exists in dmesg results.

Closing, this is a firmware bug. Please contact your firmware vendor for a fix.