Cpufreq drivers not working on T480S

User Support Hardware Issues
1

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

2

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.

3

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”.

4

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?

5

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)

6

[Deleted]

7

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.

8

@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
9

Ok

1 Like
10

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