https://bugzilla.suse.com/show_bug.cgi?id=1185513 https://bugzilla.suse.com/show_bug.cgi?id=1185513#c42 --- Comment #42 from Joey Lee <jlee@suse.com> --- Hi Anthony, Thanks for your dmesg! It's useful! (In reply to Anthony Agelastos from comment #41) [...snip]
{{{
dmesg | grep 'ACPI Debug' [ 0.171855] ACPI Debug: "_PR.PR00._OSC" [ 0.172231] ACPI Debug: "Method (GCAP, 1, Serialized)" [ 0.173426] ACPI Debug: "If ((OSYS >= 0x07DF))" [ 0.173452] ACPI Debug: "If (((CFGD & 0x00400000) && !(SDTL & 0x40)))" [ 0.174382] ACPI Debug: "_SB._OSC" [ 0.174401] ACPI Debug: "If ((Arg0 == ToUUID (0811b06e-4a27-44f9-8d60-3cbbc22e7b48)" [ 0.174406] ACPI Debug: "If ((Arg1 == One))" [ 0.174415] ACPI Debug: "If (OSCP & 0x40)" <-- first time _OSC has 0x40 [ 0.174461] ACPI Debug: "_SB._OSC" [ 0.174478] ACPI Debug: "If ((Arg0 == ToUUID (0811b06e-4a27-44f9-8d60-3cbbc22e7b48)" [ 0.174483] ACPI Debug: "If ((Arg1 == One))" <-- second time _OSC doesn't have 0x40 [ 0.174520] ACPI Debug: "_PR.PR00._PDC" [ 0.174609] ACPI Debug: "Method (GCAP, 1, Serialized)" [ 0.175617] ACPI Debug: "If ((OSYS >= 0x07DF))" [ 0.175641] ACPI Debug: "If (((CFGD & 0x00400000) && !(SDTL & 0x40)))" }}}
The _SB._OSC method be called two times. I found 0x40 (CPPC 2 Support) in the first time. But the second time doesn't raise 0x40 CPPC 2 Support bit. That's why the SSDT11 can not be loaded in _PR.PR00._PDC.GCAP . Linux OSPM calls _OSC two times is a new behavior be introduced by 719e1f561afb kernel patch since v5.12-rc1. I believe that 719e1f561afb causes this issue. Base on ACPI spec 6.4, this is a firmware issue. In the spec 6.2.11 _OSC section, it recommends that OSPM should use query mode to call _OSC first, platform should returns what capabilities are supported by platform. Then OSPM calls _OSC again base on platform's return values to set capabilities. In DSDT from your machine, firmware returns that second dword of _SB._OSC is 0x3B. Which means that the 0x40 CPPC 2 Support bit be cleared by firmware. Then OSPM use firmware's return value to call _OSC again to set capabilitites. Firmware clears CPPC2 support bit, so the SSDT11 is not dynamic loaded. Which means no \_PR.PR00._CPC. But other _CPC in PR01-PR11 still call PR00._CPC. So we saw the ACPI Error in your bug description. Before v5.12 kernel, OSPM didn't follow ACPI 6.4 spec's suggestion to apply the two steps behavior. In v5.11, OSPM just calls _OSC one time to set capability. It did not use query mode of _OSC to ask platform's capabilities. So we did not see the ACPI Erro in v5.11 kernel. -- You are receiving this mail because: You are on the CC list for the bug.