Bug #623
openOn T480/S, missing P-state data from ACPI tables prevents Xen from performing frequency scaling
0%
Description
Hello
Currently, P-state data is missing from ACPI tables on T480/S. On my T480S running libreboot, this was confirmed by using the iasl command to decompile the tables at /sys/firmware/acpi/tables/; grepping for _PSS, _PCT and _PPC didn't return any results. Another user has confirmed that this is also the case for the similar T480 device, with latest release build of libreboot (26.01 RC1).
Meanwhile, in the vendor T480S BIOS, this data is present (contributed by @henk on #coreboot IRC channel):
# grep -r -e _PCT -e _PPC -e _PSS *.dsl
DSDT.dsl: If (CondRefOf (\_PR.PR00._PPC))
DSDT.dsl: If ((CondRefOf (\_PR.PR00._PSS) && CondRefOf (\_PR.PR00._PPC)))
SSDT1.dsl: External (_PR_.PR00._PSS, MethodObj) // 0 Arguments
SSDT1.dsl: Name (_PPC, Zero) // _PPC: Performance Present Capabilities
SSDT1.dsl: If (CondRefOf (\_PR.PR00._PSS))
SSDT1.dsl: Method (_PSS, 0, NotSerialized) // _PSS: Performance Supported States
SSDT1.dsl: If (CondRefOf (\_PR.PR00._PSS))
SSDT1.dsl: Return (\_PR.PR00._PSS ())
SSDT1.dsl: If (CondRefOf (\_PR.PR00._PSS))
SSDT8.dsl: If (CondRefOf (\_PR.PR00._PSS))
The Linux kernel doesn't rely on this data to perform frequency scaling, because native support is provided by the intel_pstate driver. However, the Xen kernel lacks this native support. When the data is missing, as in my case, the Xen-based QubesOS runs underclocked and is only barely usable.
HH Updated by herme herme about 1 month ago
- Description updated (diff)
IB Updated by Ivi Ballou 26 days ago · Edited
herme herme wrote:
Hello
Currently, P-state data is missing from ACPI tables on T480/S. On my T480S running libreboot, this was confirmed by using the iasl command to decompile the tables at
/sys/firmware/acpi/tables/; grepping for_PSS,_PCTand_PPCdidn't return any results. Another user has confirmed that this is also the case for the similar T480 device, with latest release build of libreboot (26.01 RC1).Meanwhile, in the vendor T480S BIOS, this data is present (contributed by @henk on #coreboot IRC channel):
# grep -r -e _PCT -e _PPC -e _PSS *.dsl DSDT.dsl: If (CondRefOf (\_PR.PR00._PPC)) DSDT.dsl: If ((CondRefOf (\_PR.PR00._PSS) && CondRefOf (\_PR.PR00._PPC))) SSDT1.dsl: External (_PR_.PR00._PSS, MethodObj) // 0 Arguments SSDT1.dsl: Name (_PPC, Zero) // _PPC: Performance Present Capabilities SSDT1.dsl: If (CondRefOf (\_PR.PR00._PSS)) SSDT1.dsl: Method (_PSS, 0, NotSerialized) // _PSS: Performance Supported States SSDT1.dsl: If (CondRefOf (\_PR.PR00._PSS)) SSDT1.dsl: Return (\_PR.PR00._PSS ()) SSDT1.dsl: If (CondRefOf (\_PR.PR00._PSS)) SSDT8.dsl: If (CondRefOf (\_PR.PR00._PSS))The Linux kernel doesn't rely on this data to perform frequency scaling, because native support is provided by the intel_pstate driver. However, the Xen kernel lacks this native support. When the data is missing, as in my case, the Xen-based QubesOS runs underclocked and is only barely usable.
Hi!
Could you include the entire .dsl files? I might be able to add the missing entries, but I'd need to know what the vendor BIOS does. Thanks :)
PR Updated by Patrick Rudolph 26 days ago
Set register "eist_enable" = "true" in devicetree.cb?
HH Updated by herme herme 18 days ago · Edited
Hi Ivi, many thanks for taking an interest in this issue! I was able to obtain the following:
- A dump using the method described in the first post, for a T480S motherboard; Bios Version: N22ET62W (1.39), CPU: i5-8350U. Courtesy of cepawiel at the Libreboot issue tracker. The files are here: https://codeberg.org/attachments/f669fca0-90d2-48c9-9602-c9aa20102440
- One dump for T480 (Model: 20L5000UUS) and two dumps for T480S (Models: 20L7S00600 and 20L8S7PP06). These dumps are part of the repo for the https://linux-hardware.org/ project, which provides their own tool for dumping the ACPI tables. The actual data is uploaded by anonymous volunteers.
There is some variation across T480/S models (e.g several different CPU models and dozens of device models). I didn't know if this makes a difference, which is why I tried to include more than one source (but my guess is if the motherboard is the same, then it shouldn't matter). Please let me know in case you think additional dumps might be useful and I'll try to find more volunteers.
PR Updated by Patrick Rudolph 17 days ago
Should be fixed by https://review.coreboot.org/c/coreboot/+/91173