------- Comment #1 from konrad.wilk@xxxxxxxxxx 2011-10-07 08:18 -------
Copying what I said on the RH BZ:
Thanks for posting it in the Xen BZ. The issue is .. well, it is a long
explanation, so skip to the end for summary if you don't want to read technical
On AMD with Xen, the cpuidle is set to use the halt one (this is b/c the halt
ends up doing a yield hypercall) - look in setup.c - and the hypervisor does
the appropiate halt operation (MWAIT, halt, etc, or schedules another guest on
the CPU). Anyhow, to not have the cpuidle trying to activate, the
"boot_option_idle_override" is set. Therefore, the ACPI _PSS driver
(processor.ko) ends up bailing out, b/c of that parameter. As such the "older"
AMD pstate driver is invoked (powernow-k8), and the older driver attempts to
use ACPI _PSD - but only if in UP mode, or it attempts to use the voltage
tables - which are k8 or earlier. To detect that, it use the MSR (sadly not
CPUID values), which Xen traps and returns 00, which the powernow-k8 driver
interprets as "buggy hardware - can't use". Which is exactly what you are
I believe (and sadly I don't have the hardware to check this - but I think I
saw the somebody using it) if you were running on K8 hardware - it ought to
Solution: Have the ACPI processor driver cooperate with Xen. Patches are in the
queue for it (if you are really interested look in oss.oracle.com/kwilk/xen.git
#devel/acpi-cpufreq.v2 - but they are not yet upstream-able material. Actually,
they are quite ugly).
The "easy" option for right now would be to do what Dave suggest until the
upstream patches are ready and reviewed.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Xen-bugs mailing list