Bug 156893
Summary: | Xen / Xen0 kernel don't have any cpufreq support | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Paul Jakma <paul+rhbugz> |
Component: | kernel-xen | Assignee: | Rik van Riel <riel> |
Status: | CLOSED UPSTREAM | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | belegdol, davej, djuran, k.georgiou, mszpak, oliva, quintela, tomek, wtogami, xen-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-01-02 22:23:23 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Paul Jakma
2005-05-04 22:44:00 UTC
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: http://bugzilla.xensource.com/ 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. Thank you. Hi Rik, I've opened Xen bugzilla #33: http://bugzilla.xensource.com/cgi-bin/bugzilla/show_bug.cgi?id=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 :) ). bedankt, Paul Jakma. This is fixed upstream, but latest xen kernels in FC4 don't seem to have ACPI support enabled. Any chance of it? ;) thanks, --paulj Interesting. 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 (2.6.13.2). 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. Thanks. Hi Dave, I can't test 2.6.13-1.1526_FC4 due to bug #169157, I get the same message: (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) Domain 0 allocation is too small for kernel image. (XEN) **************************************** (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 yet. :( regards, --paulj 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. Thank you. 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. |