[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#619573: marked as done (xen-linux-system-2.6.32-5-xen-amd64: cpufreq scaling in Dom0 does not work)

Your message dated Fri, 25 Mar 2011 12:43:34 +0000
with message-id <1301057014.26693.561.camel@localhost>
and subject line Re: Bug#619573: xen-linux-system-2.6.32-5-xen-amd64: cpufreq scaling in Dom0 does not work
has caused the Debian Bug report #619573,
regarding xen-linux-system-2.6.32-5-xen-amd64: cpufreq scaling in Dom0 does not work
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
619573: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619573
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: xen-linux-system-2.6.32-5-xen-amd64
Version: 2.6.32-31
Severity: normal

When booting the 2.6.32-5-xen-amd64 kernel natively, CPU frequency scaling works as 
expected: after installing cpufrequtils, the CPU clocks down as it should and tools 
like powertop show the CPU's P-states.

When booting the kernel as Dom0 on Xen 4.0.1 however, messages like
> [   15.778182] powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 
> 4800+ processors (2 cpu cores) (version 2.20.00)
> [   15.778195] [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objects 
> found.
> [   15.778197] [Firmware Bug]: powernow-k8: Try again with latest BIOS.
are logged upon boot, suggesting that Xen somehow prevents the kernel from accessing 
the P-states ACPI objects and as a result, cpufrequtils fail to start:
> CPUFreq Utilities: Setting ondemand CPUFreq governor...disabled, governor 
> not available...done.
and the CPU does not clock down.

Adding cpufreq=dom0-kernel to the xen.gz line in my Grub2 config does not help, and
adding dom0_vcpus_pin (which as far as I can tell from the Xen source is implied by
cpufreq=dom0-kernel anyway) and/or cpuidle does not make a difference either.
cpufreq=xen is not supported on the AMD K8 system and does not fix the issue on the 
Intel either (xenpm get-cpufreq-states still doesn't show anything).

I observed this on both an AMD Athlon 64 X2 (K8 family), which uses the powernow-k8.ko 
module, and an Intel Pentium D, which uses the acpi-cpufreq.ko module.
Both systems supply their _PSS objects using the SSDT. Out of curiosity, on the AMD 
system, I decompiled both the DSDT and SSDT and manually merged the _PSS sections into 
the DSDT. I then injected it using Grub2's acpi command, but it didn't make any 
difference, suggesting that it has nothing to do with which table the objects are stored 
in.

Also, manually dumping the tables from /sys/firmware/acpi/tables/* looks exactly the 
same both in Dom0 mode and natively, suggesting that Xen doesn't actually touch the ACPI 
tables, but rather the cpufreq kernel module fails to look in the right spot.

-- System Information:
Debian Release: 6.0.1
  APT prefers squeeze-updates
  APT policy: (500, 'squeeze-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xen-linux-system-2.6.32-5-xen-amd64 depends on:
ii  linux-image-2.6.32-5-xen-amd6 2.6.32-31  Linux 2.6.32 for 64-bit PCs, Xen d
ii  xen-hypervisor-4.0-amd64 [xen 4.0.1-2    The Xen Hypervisor on AMD64

xen-linux-system-2.6.32-5-xen-amd64 recommends no packages.

xen-linux-system-2.6.32-5-xen-amd64 suggests no packages.

-- no debconf information

--- End Message ---
--- Begin Message --- 
On Fri, 2011-03-25 at 10:53 +0100, Michael Kuron wrote:
> Package: xen-linux-system-2.6.32-5-xen-amd64
> Version: 2.6.32-31
> Severity: normal
> 
> When booting the 2.6.32-5-xen-amd64 kernel natively, CPU frequency scaling works as 
> expected: after installing cpufrequtils, the CPU clocks down as it should and tools 
> like powertop show the CPU's P-states.
> 
> When booting the kernel as Dom0 on Xen 4.0.1 however, messages like
> > [   15.778182] powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 
> > 4800+ processors (2 cpu cores) (version 2.20.00)
> > [   15.778195] [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objects 
> > found.
> > [   15.778197] [Firmware Bug]: powernow-k8: Try again with latest BIOS.
> are logged upon boot, suggesting that Xen somehow prevents the kernel from accessing 
> the P-states ACPI objects and as a result, cpufrequtils fail to start:
> > CPUFreq Utilities: Setting ondemand CPUFreq governor...disabled, governor 
> > not available...done.
> and the CPU does not clock down.
[...]

Well, yes.  dom0 works with *virtual* CPUs.  Any physical CPU frequency
scaling must be done by the hypervisor.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: