HI,
On 6/7/21 11:43 AM, Hans de Goede wrote:
> Hi,
>
> On 6/3/21 7:26 PM, Hans de Goede wrote:
>> Hi Rafael,
>>
>> I've been helping some users with trying to get to the bottom of some
>> new ACPI errors with kernel 5.12, see:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=213023
>>
>> After looking at dmesg output; and after editing the dmesg output
>> a bit so that I could do diff -u on it, the following stands out:
>>
>> --- dmesg_5.10.38-1-lts 2021-06-03 16:29:41.372922210 +0200
>> +++ dmesg_linux-5.12.5-arch1-1 2021-06-03 16:30:01.013031634 +0200
>> @@ -92,7 +92,7 @@
>> ACPI: IRQ9 used by override.
>> Using ACPI (MADT) for SMP configuration information
>> ACPI: HPET id: 0x8086a201 base: 0xfed00000
>> -ACPI: Core revision 20200925
>> +ACPI: Core revision 20210105
>> PM: Registering ACPI NVS region [mem 0x7156c000-0x7156cfff] (4096 bytes)
>> PM: Registering ACPI NVS region [mem 0x8a88f000-0x8af7efff] (7274496 bytes)
>> ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
>> @@ -113,10 +113,6 @@
>> ACPI: Dynamic OEM Table Load:
>> ACPI: SSDT 0xFFFF... 0003FF (v02 PmRef Cpu0Cst 00003001 INTL 20160527)
>> ACPI: Dynamic OEM Table Load:
>> -ACPI: SSDT 0xFFFF... 0000BA (v02 PmRef Cpu0Hwp 00003000 INTL 20160527)
>> -ACPI: Dynamic OEM Table Load:
>> -ACPI: SSDT 0xFFFF... 000628 (v02 PmRef HwpLvt 00003000 INTL 20160527)
>> -ACPI: Dynamic OEM Table Load:
>> ACPI: SSDT 0xFFFF... 000D14 (v02 PmRef ApIst 00003000 INTL 20160527)
>> ACPI: Dynamic OEM Table Load:
>> ACPI: SSDT 0xFFFF... 000317 (v02 PmRef ApHwp 00003000 INTL 20160527)
>>
>> Note how for some reason the kernel is no longer loading the Cpu0Hwp and
>> HwpLvt SSDT-s ?
>>
>> Do you have any ideas what might be causing this ?
>
> Good news, a very similar bug is being tracked here:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1963717
>
> And one of the reporters there has done a git bisect and has found the commit which is causing the problem for them:
>
> """
> git-bisect points to 719e1f561afbe020ed175825a9bd25ed62ed1697 :
> "ACPI: Execute platform _OSC also with query bit clear".
>
> Tested 5.12.9 kernel with the commit reverted, and confirmed that the error
> messages are gone. (I had to revert
> 5a6a2c0f0f43676df27632d657a3f18b151a7ef8 for dependency too.)
>
> It also brings back the /sys/devices/system/cpu/cpu0/acpi_cppc which is absent
> in the stable 5.12.x
>
> Hope this helps
> """
I've taken a quick look at commit 719e1f561afb ("ACPI: Execute platform _OSC also with query bit clear") and I think I may have found the problem.
I've attached a patch which I think may fix this (and I've asked the reporters of the bugs to test this).
Regards,
Hans
>From d2ee8bc4ee24456fddef264f71628e2588e3144c Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@xxxxxxxxxx>
Date: Mon, 7 Jun 2021 11:55:57 +0200
Subject: [PATCH] ACPI: Use _OSC query results to determine caps rather then
the commit results
Commit 719e1f561afb ("ACPI: Execute platform _OSC also with query bit
clear") makes acpi_bus_osc_negotiate_platform_control() not only query
the platforms capabilities but it also commits the result back to the
firmware to let the firmware know which capabilities are supported
back by the OS.
This also moved the code to set the osc_sb_apei_support_acked,
osc_pc_lpi_support_confirmed and osc_sb_native_usb4_support_confirmed
flags to after the commit. But it seems that some BIOS-es clear the
OSC_SUPPORT_DWORD on return when the query bit is not set.
Move the checking of the capabilities back to after the _OSC call with
the query bit set to restore the old behavior.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213023
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1963717
Fixes: 719e1f561afb ("ACPI: Execute platform _OSC also with query bit clear")
Cc: Mario Limonciello <mario.limonciello@xxxxxxxxxxx>
Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
---
drivers/acpi/bus.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index be7da23fad76..1e4953c0d5c2 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -336,6 +336,10 @@ static void acpi_bus_osc_negotiate_platform_control(void)
return;
}
+ 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;
+
/*
* Now run _OSC again with query flag clear and with the caps
* supported by both the OS and the platform.
@@ -347,16 +351,6 @@ static void acpi_bus_osc_negotiate_platform_control(void)
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);
}
--
2.31.1
