Cpufreq drivers not working on T480S

System is T480s with i5-8250U and Libreboot running R4.2.

I’ve tested the following 4 configurations:

  1. Default
  2. GRUB_CMDLINE_XEN_DEFAULT="cpufreq=xen:hwp" as per [0]
  3. GRUB_CMDLINE_XEN_DEFAULT="cpufreq=dom0-kernel dom0_vcpus_pin" as per [1]
  4. GRUB_CMDLINE_XEN_DEFAULT="cpufreq=xen:performance" as per [2]

In all cases, cat /proc/cpuinfo reports the fixed value cpu Mhz: 1800, confirmed also using dmidecode. sysbench in an AppVM with max vcpus consistently reports about 1600 events per second, while the dom0 stats in the previous commands remain unchanged. xenpm start 10 | grep 'Avg freq' reports bizarre values, like 609350368 KHz.

Furthermore, the following commands were also checked in configurations 1 and 2:

$ xenpm get-cpufreq-para
[CPU0] failed to get cpufreq parameter
<...>

$ xenpm get-cpufreq-states
<no output>

$ ls /sys/devices/system/cpu/intel_pstate
<no such file>

$ sudo lsmod | grep 'cpufreq\|xen_acpi_processor'
<no output>

$ modprobe xen_acpi_processor
<no such device>

For configurations 2, 3, 4 the complete output of xl dmesg is here: [3]. Weirdly, in configurations 2 and 4, it reports: Using HWP for cpufreq.

To rule out causes independent of Xen/Qubes, I booted using a Debian Live image. sysbench consistently reported 4000 events per second, while /sys/cpuinfo reliably showed a jump from 900Mhz to 3.4GHz.

In conclusion, only under Qubes/Xen, something seems to block the scaling drivers from working on my system. To me, this seems like a bug. However when I posted about it on Github issue #4604 [4], I was repeatedly told that the Github forum wasn’t intended for this and so far there was no other engagement from the dev team. At the same time, my situation seems significantly different from what others are reporting in that thread, so I’m not sure if I should maybe bother opening a separate issue.

(censored links because new accounts can’t post links)
[0] hxxps://github.com/QubesOS/qubes-issues/issues/4604#issuecomment-1472183538
[1] hxxps://wiki.xenproject.org/wiki/Xen_power_management#Domain0_based_cpufreq
[2] hxxps://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#cpufreq
[3] hxxps://0x0.st/KC5L.txt
[4] hxxps://github.com/QubesOS/qubes-issues/issues/4604#issuecomment-3636704806

1 Like

Very weird. You could try loading the intel_pstate driver with modprobe.

In your comments above, did you use sudo with xenpm?
Xenpm doesn’t work for me without sudo.

I am using HWP and it’s working.

My only other suggestions would be trying Qubes 4.3-RC4(it’s using a newer Xen, though your platform is from 2018, should be well supported).

What do your BIOS settings say?

Perhaps post dmesg here and Xen logs.

Thanks for your reply.

sudo was used with all commands.

There aren’t really any BIOS settings as such, because it’s a minimalist Libreboot/Coreboot firmware that I compiled manually. Under Debian (and the same BIOS), cpufreq works correctly; so it seems to be isolated to Xen/Qubes, rather than a general issue with the BIOS.

Link [3] in the first post contains the logs of xl dmesg for configurations 2, 3, 4. Is this what you meant by Xen logs?

dmesg in dom0 contains the message: intel_pstate: CPU model not supported (at least under configuration 4 and I could check the others as well if needed).

I’m not sure if it makes sense to observe cpufreq in dom0 anyway, because as per link [1], cpufreq is managed by Xen (except in configuration 3, which I think is deprecated, as per link [2]). Maybe also because of this, modprobe acpi-cpufreq reports “No such device” and modprobe intel-pstate reports “Module intel-pstate not found in directory”.

I’ve been feeling quite upset, because I spent a lot of time learning and configuring Qubes to be my daily use machine, only to discover this major issue with it. I have no idea how to try to fix it or how to get someone to help me.

I’ve posted about it on the Qubes mailing list, but nobody answered. Does anybody know if it would make sense to ask for help on the Xen mailing list?

This guy was having issues with related acpi stuff, perhaps you can mess with the module load. Or see if there is a program to control CPU freq (like thinkfan)

[Deleted]

Thanks @corny, I’ve already read all forum threads that mentioned the xen-acpi-processor module, including the one you linked.

A big part of the problem is that xen-acpi-processor is refusing to load. This module is what enables dom0 to pass critical information to xen, as per https://old-list-archives.xen.org/archives/html/xen-devel/2020-01/msg02588.html. In the thread you linked, the user also reports being unable to load this module, but unfortunately the issue wasn’t investigated further.

Unless GRUB_CMDLINE_XEN_DEFAULT="cpufreq=dom0-kernel dom0_vcpus_pin" is used (which is possibly deprecated/unsupported anyway), cpufreq is actually managed by Xen, not by dom0. Hence any dom0 userspace tools would have to be aware of Xen to achieve anything useful (as per https://old-list-archives.xen.org/archives/html/xen-devel/2020-01/msg02706.html). This is the reason why xenmp exists and must be used.

@KitsuneNoBaka please remove this post. I’m concerned that the incorrect, lengthy AI-generated answer you’ve posted might discourage people from engaging with my thread and might mislead others in the same situation.

3 Likes

Ok

1 Like

I posted a report on the xen mailing list and the devs are narrowing it down to missing CPU info in the ACPI tables.

mkdir acpi-tables
cd acpi-tables
cp /sys/firmware/acpi/tables/* .
iasl -d *
grep -r -e _PCT -e _PPC -e _PSS *.dsl

This de-compiles the ACPI tables and checks for CPU info. In my case, the grep command returns nothing. This information is what Xen normally needs dom0 to upload to it.

Do you also have a librebooted T480S? If you or anyone else does, it would be very helpful if you could please run the above commands and report the results here.

For anyone interested, the thread on xen-devel mailing list is here and continued here.

1 Like

Hey! I don’t have access to my t480s atm but I have access to a t480. When I run these commands, I don’t get any output from the dsl files. I will try on a t480s when I have the chance.

Thanks @Lesser6676 . Here’s an update since my last post.

It’s now been established that libreboot (as of 26.01) indeed lacks P-state information in the ACPI tables for T480/S. As a result, Xen doesn’t receive the necessary data from dom0 and is unable to perform CPU frequency scaling.

T480S with libreboot can only run underclocked at a fixed speed of 1.8Ghz, which makes it only barely usable with Qubes. Probably a good idea to add this information to the HCL; I wish I had been aware of it.

I’ve opened a ticket on the coreboot issue tracker. Adding the missing data in the ACPI tables is probably not that difficult, but sadly nobody has answered the ticket yet. There is also a ticket on the libreboot issue tracker.

The only alternative to fix this would be for Xen to add native support for frequency scaling (meaning it wouldn’t rely on the ACPI tables anymore); this is how the Linux kernel does it, through the intel_pstate driver. I might be wrong, but I assume it’s out of scope for a micro-kernel like Xen (when they became aware of the problem, the devs on the Xen mailing list haven’t offered to do it, but I also haven’t asked).

If the coreboot ticket doesn’t get answered, I’m not sure how to proceed. Overall this is a shame, because the T480/S was the most modern device where it was actually possible to nuke Intel ME. And generally a nice machine overall for using with Qubes.

You can disable ME on nova custom laptops and dasharo MSI Z690/790. They are running CPUs 5+ years newer than T480

When I looked into libreboot t480 it seemed a hack-y solution. I can confirm that Dasharo doesn’t screw up the ACPI in a way that hamstrings the CPU freq

Using the me_cleaner tool which actually erases the ME code? As far as I know me_cleaner is not compatible with newer ME versions.

No, HAP bit disable is what all the post T480 hardware uses. There’s also a soft version but I’m not familiar with it

This is written by the me_cleaner dev

Wait, so an older version of Coreboot p-state worked?

Not as far as I know.

Ah! Ok, I missunder stood what you were saying.

Finally some good news, someone has just answered the Coreboot ticket saying they might be able to add the missing entries. However, they need to see the entries in the vendor BIOS for reference.

@Lesser6676 or anyone else with access to a T480S running the original BIOS (not libreboot), please could you upload the decompiled .dsl files? The files can be obtained using the instructions in the earlier post. Please also indicate the specific CPU model on your device, as there is some variation and I’m not sure whether it matters or not.

Thanks!

1 Like

Hey! Sure! I have a spare motherboard kicking around I will flash back to stock. I will try and get that done today.

(I will try to get to it tommorow, it’s been a super busy day…)

1 Like