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.