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.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1078619

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1078619/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to