Red Hat Bugzilla – Bug 156893
Xen / Xen0 kernel don't have any cpufreq support
Last modified: 2009-12-14 15:39:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050323 Galeon/1.3.20
Description of problem:
There does not appear to be any support for cpufreq in either Xen or the xen0 kernel:
# dmesg |grep clock
# dmesg |grep p4
# xm dmesg | grep clock
(XEN) ..... CPU clock speed is 2800.1059 MHz.
(XEN) ..... host bus clock speed is 200.0075 MHz.
# xm dmesg | grep p4
# modprobe p4-clockmod
FATAL: Module p4_clockmod not found.
# uname -r
I don't know whether this is a technical limitation of Xen (that it's simply not possible yet to have xen0 manage frequency), or whether it's an oversight and the xen0 kernel accidently does not include the cpufreq drivers (i hope so :) ), however it would be really nice to have either Xen or xen0 support cpufreq.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Observe bootup dmesg's of Xen and xen0
2. Notice lack of cpufreq/p4-clockmod init messages or p4-clockmod driver in xen0
3. Observe the largely idle single CPU Xeon box sucking about 1A of current and 230W of power doing very very little ;)
This is a current limitation of the upstream Xen code, and may be fixable now
thate the ACPI code has moved to the domain 0 code.
Since Xen is still a project that is very much in flux, I would ask that you
open this bug report with the upstream developers, at:
This way we can gather all Xen deficiencies in one place, and try to get them
fixed in the upstream codebase before Xen 3.0.
I've opened Xen bugzilla #33:
It states acpi-cpufreq should now be possible in 'unstable'. So hopefully next
respin of 'xen' and 'kernel-xen0' packages will includes this? (hint hint :) ).
This is fixed upstream, but latest xen kernels in FC4 don't seem to have ACPI
support enabled. Any chance of it? ;)
I have ACPI in the generated config files here, but it looks like "make ARCH=xen
menuconfig" isn't allowing me to switch ACPI on!
Thanks for catching this bug.
Mass update to all FC4 bugs:
An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (184.108.40.206). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.
Please retest with this update, and update this bug if necessary.
I can't test 2.6.13-1.1526_FC4 due to bug #169157, I get the same message:
(XEN) Panic on CPU 0:
(XEN) Domain 0 allocation is too small for kernel image.
(and that's using Rik's test Xen package too).
AFAIK, Rik is aware of the ACPI problem - it's not compiling with Xen enabled. I
don't know if he's figured it out yet, but if he did for 1526, I can't test it
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.
I havn't managed to get any kernel past kernel-xen0-2.6.12-1.1454_FC4 to boot.
So I can't test this.
Tried with 2.6.15-1.40_FC5hypervisor from FC5test2 + yum updates (this morning).
There's no p4-clockmod module supplied, and the acpi-cpufreq module refuses to
load with "No such device".
Just tried kernel-xen-hypervisor-2.6.15-1.1948_FC5.x86_64, and found out it
doesn't create /sys/devices/system/cpu/cpu*/cpufreq that the cpuspeed daemon
requires in order to switch the CPU speed dynamically.
That's probably hardware-dependent --- cpufreq works for me on my Centrino
laptop. But it still needs a bit of work to make it aware of domU activity when
setting cpufreq, and to enable certain drivers that don't work right now.
I'm using FC5 with Xen and all updates on dual Opteron 275 (dual-core) server.
With latest BIOS, powernow-k8 works with plain FC5, but DO NOT WORK with Xen
kernel. Which is very sad.
Standerd Xen kernel in FC6 and updated kernel-xen-2.6.18-1.2849.fc6.i686.rpm
don't have acpi-cpufreq.ko module. This causes lack of "cpufreq".
This module is available in PAE kernel.
Are there any techinal limitations related with Xen in that field?
Btw, if you think it's a new problem and a new thread should be opened, please
let me know.
Just for record: issue is still present in kernel 2.6.20-1.2933.fc6xen
Known problem, we are working on this upstream.
Note that just enabling the cpufreq drivers is *NOT* enough, because that way
dom0 would slow down the CPUs even if the guests were really busy.
We also need a way to figure out how busy each physical CPU is, and a way to
recalibrate the TSC rates in the timer code in the hypervisor...
change QA contact
Fixes for this issue are in the upstream Xen codebase, as well as in the
codebase that will become RHEL 5.2.