구차니의 잡동사니 모음

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

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

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

Other solution:
The "easy" option for right now would be to do what Dave suggest until the
upstream patches are ready and reviewed.

---


Just to add, per Konrad's comment above.

This issue also occurs on K8 hardware (Athlon II 4850e) with powernow enabled
in the BIOS (aka Cool'n'quiet).

Disabling Cool'n'quiet removes the messages.

I just performed the standard Desktop install of the F16 Beta, installed Xen,
rebuilt the grub menu, and rebooted to dom0.  Syslog is full of the same
message per this bug.

It would be great to see Dave's solution (see comment 5 above); an interim
kernel-patch solution to this bug - as it currently stands dom0 functionality
is largely unuseable.