similar to: cpufreq & ACPI

Dear all, The cpufreq modules have been distributed in Centos. But recently, I met a problem when I tried to test the power-related applications. The module can not be modprobed in kernel notwithstanding releated with Centos distribution. The messgae thrown out is: ------------- dump of screen ------------ # modprobe p4-clockmod.ko FATAL: Module p4_clockmod.ko not found

.. snip.. >> Both of them (acpi-cpufreq.c and powernow-k8.c) have a symbol >> dependency on drivers/acpi/processor.c > > But them being ''m'' or ''y'' shouldn''t matter in the end. I thought you were saying it matters - as it should be done around the same time as cpufreq drivers were loaded? .. snip.. >> For a), this would mean some

Hi, I noticed that the fan of my centrino is very often running since I use Xen (the load is very low still). Also the cpufreq is always at 600MHz (the max is 1500MHz), regardless of what of what heavy computations I do (e.g. calculating md5sums). I heard that it is not possible to run a cpufreq scheduler like powernowd or cpufreqd, but would it be possible to set the cpu frequency at least

Currently xen-unstable.hg is broken on ia64 and it should be fixed by Yu''s patch. However he is off this week, so I''m sending the workaround patch. [IA64] Compilation fix to cpufreq stuff. This patch fixes the following compilation error by defining stubs. This patch is just band aid patch until those functions are implemented later. > .../xen/drivers/built_in.o: In

struct cpufreq_policy, including a cpumask_t member, gets copied in cpufreq_limit_change(), cpufreq_add_cpu(), set_cpufreq_gov(), and set_cpufreq_para(). Make the member a cpumask_var_t, thus reducing the amount of data needing copying (particularly with large NR_CPUS). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- 2011-09-20.orig/xen/arch/x86/acpi/cpufreq/cpufreq.c 2011-10-12

Hi, i''m not sure if i understood the new acpi xen cpufreq driver - here''s the output when loading xen_acpi_processor module in linux 3.4: dom0 dmesg: [ 32.728151] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU8 [ 32.728156] xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU9 [ 32.728160] xen-acpi-processor: (CX): Hypervisor error (-22) for

Hi Konrad, The devel/acpi-cpufreq.v4 branch doesn''t seem to be merged into your linux-next branch yet. Is it still targeted for 3.3 ? I have been running your testing branch with linus his tree pulled on top of that, and it ran stable for me. Thx for all the hard work upstreaming everything ! -- Sander

Enable THERM_CONTROL MSR write for dom0 even cpufreq=xen Signed-off-by: Wei Gang <gang.wei@intel.com> diff -r bd683e0397b4 xen/arch/x86/traps.c --- a/xen/arch/x86/traps.c Tue Feb 17 22:29:38 2009 +0800 +++ b/xen/arch/x86/traps.c Wed Feb 25 11:23:01 2009 +0800 @@ -2187,10 +2187,17 @@ static int emulate_privileged_op(struct case MSR_IA32_MPERF: case MSR_IA32_APERF:

it seems getting lost, and thus resend. Thanks, Kevin -----Original Message----- From: Tian, Kevin Sent: 2008年7月24日 8:39 To: ''Jan Beulich'' Cc: Liu, Jinsong; Keir Fraser; xen-devel@lists.xensource.com; mark.langsdorf@amd.com Subject: RE: [Xen-devel] cpufreq info propagation >From: Jan Beulich >Sent: 2008年7月23日 18:13 >> >>startup info is viable. But how

... rather than after. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- 2010-06-15.orig/xen/arch/x86/acpi/cpufreq/cpufreq.c 2010-07-06 16:08:59.000000000 +0200 +++ 2010-06-15/xen/arch/x86/acpi/cpufreq/cpufreq.c 2010-07-06 16:11:48.000000000 +0200 @@ -210,9 +210,11 @@ static u32 get_cur_val(cpumask_t mask) if (!cpu_isset(cpu, mask)) cpu = first_cpu(mask); - policy =

I''m using the cpufreq=dom0-kernel hypervisor kernel parameter to enable frequency scaling on the host machines for quite some time now. Since then I started to get the "Time went backwards" message on AMD machines (not on Intel machines). It''s not a big problem, so I only research it once in a while when I stumble upon it from yet another direction. There''s

With my OQO, I get the following message when I try to suspend: cpufreq: suspend failed to assert current frequency is what timing core thinks it is. I see in /var/log/messages: kernel: acpi-cpufreq: CPU0 - ACPI performance management activated There are a number of apps and such dedicated to 'cpufreq' on the system. I have done a bit of searching and have not figured out what to do

Enable cpufreq support in Xen for AMD Operton processors by: 1) Allowing the PowerNow! driver in dom0 to write to the PowerNow! MSRs. 2) Adding the cpufreq notifier chain to time-xen.c in dom0. On a frequency change, a platform hypercall is performed to scale the frequency multiplier in the hypervisor. 3) Adding a platform hypercall to the hypervisor the scale the frequency multiplier and reset

Currently, enable/disable turbo mode on AMD is broken: $ xenpm enable-turbo-mode 0 <-- works and proper CPU MSR bit is set $ xenpm enable-turbo-mode 1 <-- silently broken, MSR bit not set Since ->turbo is per policy, when user requests to enable/disable turbo mode, we need to set the bit in all of the ->cpus that this policy affects. --- xen/arch/x86/acpi/cpufreq/powernow.c | 2

Hi all, I was wondering if cpu frequency scaling in dom0 (using the cpufreq=dom0-kernel boot parameter) may cause problems with HVM domUs? This is on Xen 3.2.1. PV domUs seem to work just fine. They adjust to the frequency change on the go. The HVM I run using the unmodified_driver drivers (also from the 3.2.1 release) seem to have very slow timers if dom0 lowers the frequency. Birger

Currently cpufreq and xenpm are out of sync. Fix cpufreq reporting of if turbo mode is enabled or not. Fix xenpm to not decode for tristate, but a boolean. Signed-off-by: Jacob Shin <jacob.shin@amd.com> --- tools/misc/xenpm.c | 14 +++----------- xen/drivers/cpufreq/utility.c | 2 +- 2 files changed, 4 insertions(+), 12 deletions(-) diff --git a/tools/misc/xenpm.c

Now that I finally got around to update our sources, I had a closer look at those changes, and apart from stylistic issues on the Linux side (part of which I may have asked for, but the result was somewhat overdone so the code is hardly legible now - I''ve got a patch queued to streamline this a little) I find it rather odd (fragile) that the who-is-in-charge information gets propagated

Hi all :) I''ve been using a tc setup for almost two years, but at some point (probably when I switched to kernel 2.6.x, but I''m not sure) it has started making something very weird. For a certain class, the rate is 125000bit and the ceil is 270000bit, but the fastest rate I get is about 75-80000bit, instead of the "promised" 125000, *with no other traffic in

Hi, I am trying to use the cpufreq driver and was unable to find the same on my xen kernel. I am currently running the folloing kernel: # uname -a Linux mbr-Dom0-3 2.6.18.8-xen #1 SMP Wed Jan 28 10:27:04 IST 2009 x86_64 x86_64 x86_64 GNU/Linux I read in certain places that some versions of Xen donot support cpufreq. But the information was not too clear. Could someone kindly tell me if cpufreq

This fixes an actual bug (failure to exit from a function after an allocation failure), an inconsistency (not removing the cpufreq_dom list member upon failure), and a latent bug (not clearing the current governor upon governor initialization failure when there was no old one; latent because the only current code path leading to this situation frees the policy upon failure and hence the governor