ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC]

[ionutnechita]

Hi Intel Kernel Team,

I observe this:

~ dmesg -l err
[    1.188193] ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20200925/psargs-330)
[    1.188201] ACPI Error: Aborting method \_PR.PR01._CPC due to previous error (AE_NOT_FOUND) (20200925/psparse-529)
[    1.188231] ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20200925/psargs-330)
[    1.188237] ACPI Error: Aborting method \_PR.PR02._CPC due to previous error (AE_NOT_FOUND) (20200925/psparse-529)
[    1.188267] ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20200925/psargs-330)
[    1.188272] ACPI Error: Aborting method \_PR.PR03._CPC due to previous error (AE_NOT_FOUND) (20200925/psparse-529)

~ dmesg -l warn
[    1.188199] No Local Variables are initialized for Method [_CPC]
[    1.188200] No Arguments are initialized for method [_CPC]
[    1.188235] No Local Variables are initialized for Method [_CPC]
[    1.188236] No Arguments are initialized for method [_CPC]
[    1.188270] No Local Variables are initialized for Method [_CPC]
[    1.188271] No Arguments are initialized for method [_CPC]

Is a kernel regression with ACPI component?

Kernel Version: 5.10.35 / 5.10.35-intel-lts-base
Branch: 5.10/yocto
HW: Intel(R) Client Systems NUC7i7BNH/NUC7i7BNB
CPU: Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz (family: 0x6, model: 0x8e, stepping: 0x9)

Attachements:
dmesg-5.10.35-intel-lts-base.txt
config-5.10.35-intel-lts-base.txt

[ionutnechita]

Hi,

I found the root cause of this bug.
It is in the file: drivers/acpi/bus.c.

[ionutnechita]

index c49b35e30..cdff9cb03 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -332,39 +332,22 @@ static void acpi_bus_osc_negotiate_platform_control(void)
 	if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", &handle)))
 		return;
 
-	if (ACPI_FAILURE(acpi_run_osc(handle, &context)))
-		return;
-
-	capbuf_ret = context.ret.pointer;
-	if (context.ret.length <= OSC_SUPPORT_DWORD) {
+	if (ACPI_SUCCESS(acpi_run_osc(handle, &context))) {
+		capbuf_ret = context.ret.pointer;
+		if (context.ret.length > OSC_SUPPORT_DWORD) {
+			osc_sb_apei_support_acked =
+				capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_APEI_SUPPORT;
+			osc_pc_lpi_support_confirmed =
+				capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_PCLPI_SUPPORT;
+			osc_sb_native_usb4_support_confirmed =
+				capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_NATIVE_USB4_SUPPORT;
+		}
 		kfree(context.ret.pointer);
-		return;
-	}
-
-	/*
-	 * Now run _OSC again with query flag clean and with the caps
-	 * both platform and OS supports.
-	 */
-	capbuf[OSC_QUERY_DWORD] = 0;
-	capbuf[OSC_SUPPORT_DWORD] = capbuf_ret[OSC_SUPPORT_DWORD];
-	kfree(context.ret.pointer);
-
-	if (ACPI_FAILURE(acpi_run_osc(handle, &context)))
-		return;
-
-	capbuf_ret = context.ret.pointer;
-	if (context.ret.length > OSC_SUPPORT_DWORD) {
-		osc_sb_apei_support_acked =
-			capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_APEI_SUPPORT;
-		osc_pc_lpi_support_confirmed =
-			capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_PCLPI_SUPPORT;
-		osc_sb_native_usb4_support_confirmed =
-			capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_NATIVE_USB4_SUPPORT;
 	}
-
-	kfree(context.ret.pointer);
+	/* do we need to check other returned cap? Sounds no */
 }
 
+
 /*
  * Native control of USB4 capabilities. If any of the tunneling bits is
  * set it means OS is in control and we use software based connection
-- 
2.30.2

[ionutnechita]

This is fixed with this patch applied.

[tcrossland]

I'm getting this issue with the same hardware on Linux 5.18, is it possible there's been a regression?

[ionutnechita]

I'm getting this issue with the same hardware on Linux 5.18, is it possible there's been a regression?

This is an old regression.
Should be fixed at 5.20 upstream.

[kmanwar89]

Chiming in here - Just fresh installed Ubuntu 22.04 on my desktop (Dual boot w/ Windows 10, Intel i7-6700k) and I'm encountering this same error. Unfortunately it's made my system completely unusable. Is there any guidance on a workaround here?

[kmanwar89]

Just wanted to add that I re-installed Ubuntu 22.04 on my desktop and encountered the exact same behavior after performing a "sudo apt-get autoremove"; that seems to be the "trigger" for reproducing the issue on a fresh install.

[kc97ble]

Chiming in here - Just fresh installed Ubuntu 22.04 on my desktop (Dual boot w/ Windows 10, Intel i7-6700k) and I'm encountering this same error. Unfortunately it's made my system completely unusable. Is there any guidance on a workaround here?

I also encountered this issue since a few days ago. My system now freezes randomly, nearly unusable.

EDIT: I am trying two workarounds:

1. Install Kubuntu 18.04 LTS
2. Keep Kubuntu 22.04 LTS and use kernel version 5.15.0-25

In both workarounds, dmesg no longer emits "ACPI BIOS Error (bug): Could not resolve symbol [_PR.PR00._CPC]".

It seems that there must be some changes between 5.15.0-25 and 5.15.0-47.

[kmanwar89]

I ended up removing Ubuntu altogether and installing Linux Mint - the messages are present, but are no longer completely nuking my install.

As a comparison, I have another Intel machine (Lenovo laptop with an 11th generation Intel i7) running Pop!_OS - I successfully upgraded between versions (corresponding to 21.10 --> 22.04) and it has no issues.

I'm not sure if there's some regression in code affecting older CPU's, but I've never seen these messages until recently. I've had this desktop since 2016 and have run various flavors of Linux on it for years - something is definitely off here, I just can't tell what. Happy to help someone with more knowledge than I troubleshoot extensively, if they'd like.