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