--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: xen-linux-system-2.6.32-5-xen-amd64: cpufreq scaling in Dom0 does not work
- From: Michael Kuron <mkbug@quantentunnel.de>
- Date: Fri, 25 Mar 2011 10:53:47 +0100
- Message-id: <20110325095347.1768.95961.reportbug@mkuron-pc.home.kuron-germany.de>
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 ---
- To: 619573-done@bugs.debian.org
- Subject: Closing bugs assigned to linux-2.6 package
- From: Ben Hutchings <benh@debian.org>
- Date: Sun, 29 May 2016 21:00:31 +0100
- Message-id: 0ca02ed2-e0c5-4913-be7f-79b6b434cd1c@decadent.org.uk
Version: 3.4.1-1~experimental.1+rm
Debian 6.0 Long Term Support has ended, and the 'linux-2.6' source
package will no longer be updated. This bug was reassigned to the
'linux' source package earlier today, but I am now closing it on the
assumption that it does not affect the kernel versions in newer Debian
releases.
If you can still reproduce this bug in a newer release, please reopen
the bug report and reassign it to 'src:linux' and the affected version
of the package. You can find the package version for the running
kernel by running:
uname -v
or the versions of all installed kernel packages by running:
dpkg -l 'linux-image-[34]*' | grep ^.i
and looking at the third column.
I apologise that we weren't able to provide a specific resolution for
this bug.
Ben.
--
Ben Hutchings - Debian developer, member of Linux kernel and LTS teams
--- End Message ---