I can confirm that the ACPI BIOS Errors no longer appear in the kernel log using mainline 5.19.0-rc5 with the patch applied.
Many thanks
On Thu, Jul 7, 2022 at 11:36 PM Limonciello, Mario Mario.Limonciello@amd.com wrote:
[Public]
-----Original Message----- From: Tom Crossland tomc@fortu.net Sent: Thursday, July 7, 2022 16:31 To: Sasha Levin sashal@kernel.org; linux-kernel@vger.kernel.org; stable@vger.kernel.org Cc: Rafael J. Wysocki rafael.j.wysocki@intel.com; Limonciello, Mario Mario.Limonciello@amd.com; Huang, Ray Ray.Huang@amd.com; Mika Westerberg mika.westerberg@linux.intel.com; rafael@kernel.org; linux- acpi@vger.kernel.org Subject: Re: [PATCH AUTOSEL 5.17 42/43] Revert "ACPI: Pass the same capabilities to the _OSC regardless of the query flag"
Hi, I'm observing the issue described here which I think is due to a recent regression:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c om%2Fintel%2Flinux-intel- lts%2Fissues%2F22&data=05%7C01%7CMario.Limonciello%40amd.com%7 C77419b612f9540e333ff08da606002ee%7C3dd8961fe4884e608e11a82d994e18 3d%7C0%7C0%7C637928263354159054%7CUnknown%7CTWFpbGZsb3d8eyJWI joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 0%7C%7C%7C&sdata=X%2FEAU9GbRD%2FfYxCMUmnWI1cJ8dk8sICk0iYu %2BKGqtl4%3D&reserved=0
sudo dmesg -t -l err
ACPI BIOS Error (bug): Could not resolve symbol [_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330) ACPI Error: Aborting method _PR.PR01._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529) ACPI BIOS Error (bug): Could not resolve symbol [_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330) ACPI Error: Aborting method _PR.PR02._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529) ACPI BIOS Error (bug): Could not resolve symbol [_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330) ACPI Error: Aborting method _PR.PR03._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529)
System: Kernel: 5.18.9-arch1-1 arch: x86_64 bits: 64 compiler: gcc v: 12.1.0 parameters: initrd=\intel-ucode.img initrd=\initramfs-linux.img root=xxx intel_iommu=on iommu=pt Machine: Type: Desktop Mobo: Intel model: NUC7i5BNB v: J31144-304 serial: <filter> UEFI: Intel v: BNKBL357.86A.0088.2022.0125.1102 date: 01/25/2022
I hope this is the correct forum to report the issue. Apologies if not.
This is the fix for it:
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?...
On 28/03/2022 13.18, Sasha Levin wrote:
From: "Rafael J. Wysocki" rafael.j.wysocki@intel.com
[ Upstream commit 2ca8e6285250c07a2e5a22ecbfd59b5a4ef73484 ]
Revert commit 159d8c274fd9 ("ACPI: Pass the same capabilities to the _OSC regardless of the query flag") which caused legitimate usage scenarios (when the platform firmware does not want the OS to control certain platform features controlled by the system bus scope _OSC) to break and was misguided by some misleading language in the _OSC definition in the ACPI specification (in particular, Section 6.2.11.1.3 "Sequence of _OSC Calls" that contradicts other perts of the _OSC definition).
Link:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ker nel.org%2Flinux- acpi%2FCAJZ5v0iStA0JmO0H3z%2BVgQsVuQONVjKPpw0F5HKfiq%3DGb6B5yw% 40mail.gmail.com&data=05%7C01%7CMario.Limonciello%40amd.com%7C 77419b612f9540e333ff08da606002ee%7C3dd8961fe4884e608e11a82d994e183 d%7C0%7C0%7C637928263354159054%7CUnknown%7CTWFpbGZsb3d8eyJWIj oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 0%7C%7C%7C&sdata=Te3BK%2B0q2QmrqqoG5mbV%2FNguoMgiwzILNHl %2BhUMLFlY%3D&reserved=0
Reported-by: Mario Limonciello Mario.Limonciello@amd.com Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Tested-by: Mario Limonciello mario.limonciello@amd.com Acked-by: Huang Rui ray.huang@amd.com Reviewed-by: Mika Westerberg mika.westerberg@linux.intel.com Signed-off-by: Sasha Levin sashal@kernel.org
drivers/acpi/bus.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index 07f604832fd6..079b952ab59f 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -332,21 +332,32 @@ static void
acpi_bus_osc_negotiate_platform_control(void)
if (ACPI_FAILURE(acpi_run_osc(handle, &context))) return;
- kfree(context.ret.pointer);
- capbuf_ret = context.ret.pointer;
- if (context.ret.length <= OSC_SUPPORT_DWORD) {
kfree(context.ret.pointer);return;- }
- /* Now run _OSC again with query flag clear */
- /*
- Now run _OSC again with query flag clear and with the caps
- supported by both the OS and the platform.
- */ 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;
- 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;
- 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); }