Ubuntu
linux package

[raring] xen power managment (freq scaling) fails on linux 3.7

Bug #1078619 reported by Stefan Bader
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

While testing the current 3.7.0-0.5 kernel together with the Xen 4.2 package I noticed that "xenpm get-cpufreq-para 0" would weirdly report only one available frequency. Booting back into kernel 3.5.0-18.29 with the same userspace shows the expected output:

cpu id : 0
affected_cpus : 0
cpuinfo frequency : max [2000000] min [800000] cur [800000]
scaling_driver :
scaling_avail_gov : userspace performance powersave ondemand
current_governor : ondemand
  ondemand specific :
    sampling_rate : max [10000000] min [10000] cur [20000]
    up_threshold : 80
scaling_avail_freq : 2000000 1500000 1200000 1000000 *800000
scaling frequency : max [2000000] min [800000] cur [800000]

Bad output on 3.7:

cpu id : 0
affected_cpus : 0
cpuinfo frequency : max [1600000] min [1600000] cur [1600000]
scaling_driver :
scaling_avail_gov : userspace performance powersave ondemand
current_governor : ondemand
  ondemand specific :
    sampling_rate : max [10000000] min [10000] cur [20000]
    up_threshold : 80
scaling_avail_freq : *1600000 *1600000 *1600000 *1600000 *1600000
scaling frequency : max [1600000] min [1600000] cur [1600000]

See original description
Tags: raring
Revision history for this message
Stefan Bader (smb) wrote :
Changed in linux (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Stefan Bader (smb) wrote :

The dmesg of 3.7 contains a lot of "Firmware Bug" messages. Possibly something goes wrong there...

Stefan Bader (smb)
description: updated
Revision history for this message
Konrad Rzeszutek Wilk (konrad-wilk) wrote :

Hm
I don't know what Ubuntu's 3.7 contains, but if I run the v3.6 vanilla on an Intel SWQ6710H.86A.0052.2011.0520.1802
(i5-2100) I get:
> xenpm get-cpufreq-para
 cpu id : 0
affected_cpus : 0
cpuinfo frequency : max [3301000] min [1600000] cur [3300000]
scaling_driver : acpi-cpufreq
scaling_avail_gov : userspace performance powersave ondemand
current_governor : ondemand
  ondemand specific :
    sampling_rate : max [10000000] min [10000] cur [20000]
    up_threshold : 80
scaling_avail_freq : 3301000 3300000 3100000 2900000 2700000 2500000 2300000 2100000 1900000 1700000 *1600000
scaling frequency : max [3301000] min [1600000] cur [1600000]
turbo mode : enabled

and with v3.7-rc5:
 xenpm get-cpufreq-para
cpu id : 0
affected_cpus : 0
cpuinfo frequency : max [3301000] min [1600000] cur [3300000]
scaling_driver : acpi-cpufreq
scaling_avail_gov : userspace performance powersave ondemand
current_governor : ondemand
  ondemand specific :
    sampling_rate : max [10000000] min [10000] cur [20000]
    up_threshold : 80
scaling_avail_freq : 3301000 3300000 3100000 2900000 2700000 2500000 2300000 2100000 1900000 1700000 *1600000
scaling frequency : max [3301000] min [1600000] cur [1600000]
turbo mode : enabled

Revision history for this message
Konrad Rzeszutek Wilk (konrad-wilk) wrote :

19:40:45 # 10 :~/
> xl info
 host : tst018.dumpdata.com
release : 3.7.0-rc5upstream
version : #1 SMP Fri Nov 16 14:15:58 EST 2012
machine : x86_64
nr_cpus : 4
max_cpu_id : 3
nr_nodes : 1
cores_per_socket : 4
threads_per_core : 1
cpu_mhz : 3292
hw_caps : bfebfbff:28100800:00000000:00003f00:17bae3f7:00000000:00000001:00000000
virt_caps : hvm hvm_directio
total_memory : 16296
free_memory : 13006
sharing_freed_memory : 0
sharing_used_memory : 0
free_cpus : 0
xen_major : 4
xen_minor : 3
xen_extra : -unstable
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler : credit
xen_pagesize : 4096
platform_params : virt_start=0xffff800000000000
xen_changeset : unavailable
xen_commandline : cpufreq=verbose,performance vpmu=1 dom0_mem=max:3G apic=debug apic_verbosity=debug console=vga loglvl=all vpmu=1 guest_loglvl=all apic=debug
cc_compiler : gcc (GCC) 4.4.4 20100503 (Red Hat 4.4.4-2)
cc_compile_by : konrad
cc_compile_domain : dumpdata.com
cc_compile_date : Fri Nov 16 14:16:12 EST 2012
xend_config_format : 4

So I am looking to be also be running the latest Xen

Just curious - did you turn _off_ the machine before booting in v3.7 kernel after the upgrade? Meaning do it from a cold boot.

Joseph Salisbury (jsalisbury)
tags: added: raring
Revision history for this message
Stefan Bader (smb) wrote :

@Konrad, I think I had both, once just a reboot but also cold boots. Also things start to work again just by booting back into an older kernel. The Ubuntu 3.7 was, I think an RC3 with only quite limited changes from upstream. None of which should have an impact. But I need to keep an eye on it, there will be a more recent rc there soon and I will re-check. I opened this to remind me and give you an early heads up (or see whether you heard about it before).

Revision history for this message
Stefan Bader (smb) wrote :
Download full text (3.4 KiB)

May or may not related Xen messages:

(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000040001000000 to 0xc008040001000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000409 from 0xc000010101000000 to 0xc008010101000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010004 from 0x0000fffcaf83dad0 to 0x0000fffcaf83252f.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000040001000000 to 0xc008040001000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000409 from 0xc000010101000000 to 0xc008010101000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000040001000000 to 0xc008040001000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000409 from 0xc000010101000000 to 0xc008010101000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000040001000000 to 0xc008040001000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000409 from 0xc000010101000000 to 0xc008010101000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 0000000000000413 from 0xc00c0ffe01000000 to 0xc0080ffe01000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000050101000000 to 0xc008050101000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000409 from 0xc00001c101000000 to 0xc00801c101000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 0000000000000413 from 0xc00c0ffe01000000 to 0xc0080ffe01000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000050101000000 to 0xc008050101000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000409 from 0xc00001c101000000 to 0xc00801c101000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 0000000000000413 from 0xc00c0ffe01000000 to 0xc0080ffe01000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000050101000000 to 0xc008050101000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000409 from 0xc00001c101000000 to 0xc00801c101000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 0000000000000413 from 0xc00c0ffe01000000 to 0xc0080ffe01000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000050101000000 to 0xc008050101000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000409 from 0xc00001c101000000 to 0xc00801c101000000.
(XEN) mm.c:874: d0: Forcing read-only access to MFN e0002
(XEN) Fail change to ondemand governor
(XEN) Fail change to ondemand governor
(XEN) Fail change to ondemand governor
(XEN) Fail change to ondemand governor
(XEN) Fail change to ondemand governor
(XEN) Fail change to ondemand governor
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010020 from 0x0000000000000000 to 0xffff880003cb9c00.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010020 from 0x0000000000000000 to 0xffff880003cb9c00.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010020 from 0x0000000000000000 to 0xffff880003cb9c00.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010020 from 0x0000000000000000 to 0xffff880003cb9c00.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010020 from 0x0000000000000000 to 0xffff880003cb9c00.
(XEN) traps.c:2584:d0 Domain attempt...

Read more...

Revision history for this message
Stefan Bader (smb) wrote :

On a 3.5 kernel I only get those:

(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010004 from 0x0000fffcaf83dad0 to 0x000000000000abcd.
(XEN) mm.c:874: d0: Forcing read-only access to MFN e0002
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010020 from 0x0000000000000000 to 0xffff880029169000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010020 from 0x0000000000000000 to 0xffff880029169000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010020 from 0x0000000000000000 to 0xffff880029169000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010020 from 0x0000000000000000 to 0xffff880029169000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010020 from 0x0000000000000000 to 0xffff880029169000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010020 from 0x0000000000000000 to 0xffff880029169000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010020 from 0x0000000000000000 to 0xffff880029169000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010020 from 0x0000000000000000 to 0xffff880029169000.

Revision history for this message
Konrad Rzeszutek Wilk (konrad-wilk) wrote : Re: [Bug 1078619] Re: [raring] xen power managment (freq scaling) fails on linux 3.7
Download full text (5.4 KiB)

On Mon, Nov 19, 2012 at 10:36:45AM -0000, Stefan Bader wrote:
> May or may not related Xen messages:
>
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000040001000000 to 0xc008040001000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000409 from 0xc000010101000000 to 0xc008010101000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010004 from 0x0000fffcaf83dad0 to 0x0000fffcaf83252f.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000040001000000 to 0xc008040001000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000409 from 0xc000010101000000 to 0xc008010101000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000040001000000 to 0xc008040001000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000409 from 0xc000010101000000 to 0xc008010101000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000040001000000 to 0xc008040001000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000409 from 0xc000010101000000 to 0xc008010101000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 0000000000000413 from 0xc00c0ffe01000000 to 0xc0080ffe01000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000050101000000 to 0xc008050101000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000409 from 0xc00001c101000000 to 0xc00801c101000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 0000000000000413 from 0xc00c0ffe01000000 to 0xc0080ffe01000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000050101000000 to 0xc008050101000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000409 from 0xc00001c101000000 to 0xc00801c101000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 0000000000000413 from 0xc00c0ffe01000000 to 0xc0080ffe01000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000050101000000 to 0xc008050101000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000409 from 0xc00001c101000000 to 0xc00801c101000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 0000000000000413 from 0xc00c0ffe01000000 to 0xc0080ffe01000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000050101000000 to 0xc008050101000000.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000409 from 0xc00001c101000000 to 0xc00801c101000000.
> (XEN) mm.c:874: d0: Forcing read-only access to MFN e0002
> (XEN) Fail change to ondemand governor
> (XEN) Fail change to ondemand governor
> (XEN) Fail change to ondemand governor
> (XEN) Fail change to ondemand governor
> (XEN) Fail change to ondemand governor
> (XEN) Fail change to ondemand governor

Those look suspicious and I have to say I think I saw those
too on one of my machines - but I can't recall whether
the xenpm worked afterwards.

> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010020 from 0x0000000000000000 to 0xffff880003cb9c00.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010020 from 0x0000000000000000 to 0xffff880003cb9c00.
> (XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010020 from 0x0000000000000000 to ...

Read more...

Revision history for this message
Stefan Bader (smb) wrote :

Starting with kernel v3.7 the following commit added a quirk
to obtain the real frequencies of certain AMD systems:

commit f594065faf4f9067c2283a34619fc0714e79a98d
Author: Matthew Garrett <email address hidden>
Date: Tue Sep 4 08:28:06 2012 +0000

    ACPI: Add fixups for AMD P-state figures

When running bare-metal, on my Opteron 6128 test box results
in the frequencies remaining effectively unchanged:
[ 5.475735] P0: MSR(hi,lo): 8000015c-50004004
[ 5.479049] P0: fid=0x4, did=0x0, freq: 2000 -> 2000
[ 5.484001] P1: MSR(hi,lo): 8000014c-50004a4e
[ 5.487314] P1: fid=0xe, did=0x1, freq: 1500 -> 1500
[ 5.492272] P2: MSR(hi,lo): 80000141-50005048
[ 5.495584] P2: fid=0x8, did=0x1, freq: 1200 -> 1200
[ 5.500540] P3: MSR(hi,lo): 80000138-50005844
[ 5.503853] P3: fid=0x4, did=0x1, freq: 1000 -> 1000
[ 5.508812] P4: MSR(hi,lo): 80000131-50005c40
[ 5.512125] P4: fid=0x0, did=0x1, freq: 800 -> 800

However running as dom0 under Xen 4.2, reading this MSR returns
null:
[ 11.613068] P0: MSR(hi,lo): 00000000-00000000
[ 11.613074] P0: fid=0x0, did=0x0, freq: 2000 -> 1600
[ 11.613078] P1: MSR(hi,lo): 00000000-00000000
[ 11.613081] P1: fid=0x0, did=0x0, freq: 1500 -> 1600
[ 11.613085] P2: MSR(hi,lo): 00000000-00000000
[ 11.613088] P2: fid=0x0, did=0x0, freq: 1200 -> 1600
[ 11.613091] P3: MSR(hi,lo): 00000000-00000000
[ 11.613094] P3: fid=0x0, did=0x0, freq: 1000 -> 1600
[ 11.613098] P4: MSR(hi,lo): 00000000-00000000
[ 11.613101] P4: fid=0x0, did=0x0, freq: 800 -> 1600

And this results in Xen failing to change the governor:
  "(XEN) Fail change to ondemand governor"

I suppose this ultimately requires some support in the hypervisor
to pass through the real values. But since this is at least on my
combination of Xen 4.2 + kernel v3.7+ and AMD family 0x10 CPU a
regression compared to older kernels, I wonder whether the following
change might be something that should go into mainline:

--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -340,6 +340,9 @@ static void amd_fixup_frequency(struct acpi_processor_px *px
        if ((boot_cpu_data.x86 == 0x10 && boot_cpu_data.x86_model < 10)
            || boot_cpu_data.x86 == 0x11) {
                rdmsr(MSR_AMD_PSTATE_DEF_BASE + index, lo, hi);
+ /* Bit 63 indicates whether contents are valid */
+ if (!(hi & 0x8000000))
+ return;
                fid = lo & 0x3f;
                did = (lo >> 6) & 7;
                if (boot_cpu_data.x86 == 0x10)

I tested something similar (so hopefully I have not failed on slapping
together a cleaned up version), which did resolve the problem.

Revision history for this message
Konrad Rzeszutek Wilk (konrad-wilk) wrote :

On Mon, Jan 14, 2013 at 03:57:48PM -0000, Stefan Bader wrote:
> Starting with kernel v3.7 the following commit added a quirk
> to obtain the real frequencies of certain AMD systems:
>
> commit f594065faf4f9067c2283a34619fc0714e79a98d
> Author: Matthew Garrett <email address hidden>
> Date: Tue Sep 4 08:28:06 2012 +0000
>
> ACPI: Add fixups for AMD P-state figures
>
> When running bare-metal, on my Opteron 6128 test box results
> in the frequencies remaining effectively unchanged:
> [ 5.475735] P0: MSR(hi,lo): 8000015c-50004004
> [ 5.479049] P0: fid=0x4, did=0x0, freq: 2000 -> 2000
> [ 5.484001] P1: MSR(hi,lo): 8000014c-50004a4e
> [ 5.487314] P1: fid=0xe, did=0x1, freq: 1500 -> 1500
> [ 5.492272] P2: MSR(hi,lo): 80000141-50005048
> [ 5.495584] P2: fid=0x8, did=0x1, freq: 1200 -> 1200
> [ 5.500540] P3: MSR(hi,lo): 80000138-50005844
> [ 5.503853] P3: fid=0x4, did=0x1, freq: 1000 -> 1000
> [ 5.508812] P4: MSR(hi,lo): 80000131-50005c40
> [ 5.512125] P4: fid=0x0, did=0x1, freq: 800 -> 800
>
> However running as dom0 under Xen 4.2, reading this MSR returns
> null:
> [ 11.613068] P0: MSR(hi,lo): 00000000-00000000
> [ 11.613074] P0: fid=0x0, did=0x0, freq: 2000 -> 1600
> [ 11.613078] P1: MSR(hi,lo): 00000000-00000000
> [ 11.613081] P1: fid=0x0, did=0x0, freq: 1500 -> 1600
> [ 11.613085] P2: MSR(hi,lo): 00000000-00000000
> [ 11.613088] P2: fid=0x0, did=0x0, freq: 1200 -> 1600
> [ 11.613091] P3: MSR(hi,lo): 00000000-00000000
> [ 11.613094] P3: fid=0x0, did=0x0, freq: 1000 -> 1600
> [ 11.613098] P4: MSR(hi,lo): 00000000-00000000
> [ 11.613101] P4: fid=0x0, did=0x0, freq: 800 -> 1600
>
> And this results in Xen failing to change the governor:
> "(XEN) Fail change to ondemand governor"

Uh, when does this occur? Is tha right after those MSRs are writen?
I would have expected the Fail change to ondemand governor to
be irrespective of the dom0 change. But maybe this is with
cpufreq=dom0 on the Xen command line?

Does xenpm tell you that you got P and C states?

>
> I suppose this ultimately requires some support in the hypervisor
> to pass through the real values. But since this is at least on my
> combination of Xen 4.2 + kernel v3.7+ and AMD family 0x10 CPU a
> regression compared to older kernels, I wonder whether the following
> change might be something that should go into mainline:
>
> --- a/drivers/acpi/processor_perflib.c
> +++ b/drivers/acpi/processor_perflib.c
> @@ -340,6 +340,9 @@ static void amd_fixup_frequency(struct acpi_processor_px *px
> if ((boot_cpu_data.x86 == 0x10 && boot_cpu_data.x86_model < 10)
> || boot_cpu_data.x86 == 0x11) {
> rdmsr(MSR_AMD_PSTATE_DEF_BASE + index, lo, hi);
> + /* Bit 63 indicates whether contents are valid */
> + if (!(hi & 0x8000000))
> + return;

Looks innocent enough and a good idea to make sure that the contents
are indeed valid..
> fid = lo & 0x3f;
> did = (lo >> 6) & 7;
> if (boot_cpu_data.x86 == 0x10)
>

Revision history for this message
Stefan Bader (smb) wrote :

Actually the whole WRMSR trail is a red herring. The 00000000c0010020 ones are from trying a microcode update. The 00000000c0010004 one is checking for performance counters and 0000000000000413, 00000000c0000408 and 00000000c0000409 are related to machine check info (bank 4???). But I think all of them completely unrelated to this.

The problem really is that the new quirk in ACPI code reads the MSR which should contain frequency information but gets 0 under Xen (without any other error message as far as I can see). Without further checking this value (only based on what cpu model this is running on) it calculates the P-state frequency. And that is always 1600Mhz. That value overwrites the values that have been already obtained by (I guess) the ACPI tables. So in the end the kernel info about the P-states says all of them run at 1600MHz and that likely is considered non-sense, so the hypervisor refuses to start the ondemand governor. Or maybe it does do something but its hard to differentiate between all of the 1600MHz states... ;)

So you may have seen I started off the discussion upstream and at least one of the Andres seems to think it is something that could be considered. However this is just a compatibility work-around to some degree. It likely will still cause the incorrect frequencies used on those machines for which the quirk was introduced (running as dom0). But that would be a hv change in some place that handles the rdmsr calls. And even when that is done, it will take time to propagate into releases and installs.

Revision history for this message
Matt Wilson (msw-amazon) wrote :

See my post here: http://lists.xen.org/archives/html/xen-devel/2013-01/msg00941.html

The correct values should be returned already via rdmsr if
"cpureq=dom0-kernel" is specified on the Xen command line. Looking at
the LP report, it doesn't seem that this option was used.

Likely you will also need to use "dom0_vcpu_pin=1" if you want dom0 to
be the cpufreq controller on AMD.

Matt

Revision history for this message
Konrad Rzeszutek Wilk (konrad-wilk) wrote :

On Tue, Jan 15, 2013 at 09:55:41AM -0000, Stefan Bader wrote:
> Actually the whole WRMSR trail is a red herring. The 00000000c0010020
> ones are from trying a microcode update. The 00000000c0010004 one is
> checking for performance counters and 0000000000000413, 00000000c0000408
> and 00000000c0000409 are related to machine check info (bank 4???). But
> I think all of them completely unrelated to this.
>
> The problem really is that the new quirk in ACPI code reads the MSR
> which should contain frequency information but gets 0 under Xen (without
> any other error message as far as I can see). Without further checking
> this value (only based on what cpu model this is running on) it
> calculates the P-state frequency. And that is always 1600Mhz. That value
> overwrites the values that have been already obtained by (I guess) the
> ACPI tables. So in the end the kernel info about the P-states says all

Aaah. I see it now, .. I am really surprised that
f594065faf4f9067c2283a34619fc0714e79a98d got stuck in a generic library
but I guess the quirks have to go somewhere.

> of them run at 1600MHz and that likely is considered non-sense, so the
> hypervisor refuses to start the ondemand governor. Or maybe it does do
> something but its hard to differentiate between all of the 1600MHz
> states... ;)

<nods>

Revision history for this message
Stefan Bader (smb) wrote :

The change to check the MSR valid bit went upstream in v3.8-rc5 (Ubuntu-3.8.0-4.8)

commit 9855d8ce41a7801548a05d844db2f46c3e810166
    ACPI: Check MSR valid bit before using P-state frequencies

Changed in linux (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.