/bugzilla3/ Bug 1789 – powernow-k8 transitions fail in xen dom0
Bug 1789 - powernow-k8 transitions fail in xen dom0
: powernow-k8 transitions fail in xen dom0
Status: NEW
Product: Xen
Hardware Support
: unspecified
: x86-64 Linux
: P2 normal
Assigned To: Xen Bug List
:
:
:
  Show dependency treegraph
 
Reported: 2011-10-07 06:51 CDT by Tim Flink
Modified: 2012-11-22 13:12 CST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Flink 2011-10-07 06:51:23 CDT
I am filing this upstream from a report in the redhat bugzilla [1].

When using Fedora 16 as Dom0 with some CPUs (I'm using 2x Dual Core AMD
Opteron(tm) Processor 865 HE), the system log is flooded with messages (several
per second) like the following:

kernel: [    1.226209] powernow-k8: fid trans failed, fid 0x2, curr 0x0
kernel: [    1.226271] powernow-k8: transition frequency failed

While the system is still running with these errors, the console is pretty much
useless and all of the extra messages make the signal/noise ratio in the system
log very low.

According to the kernel maintainers, this is an issue with Xen and not the
kernel [2].

At the time of this report, I am using the following Fedora packages:
kernel-3.1.0-0.rc8.git0.1.fc16.x86_64
xen-4.1.1-6

[1] https://bugzilla.redhat.com/show_bug.cgi?id=739159
[2] https://bugzilla.redhat.com/show_bug.cgi?id=739159#c6
Comment 1 Konrad Rzeszutek Wilk 2011-10-07 08:18:22 CDT
Copying what I said on the RH BZ:
Tim,

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

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.
Comment 2 colo 2012-11-22 13:12:13 CST
This bug is still persistent.
I have compiled xen 4.2 from source on FC 17 on AMD Turion X52 cores kernel
version 3.3.4-5.fc17.x86_64 
dmesg shows a lot of powernow-k8: transition frequency failed and CPUs is
running nostop on full power