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> -- 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
