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