>> However, the work done by Sharar >> in earlier postings, in my opinion, narrows it down to either the >> microcode itself or some loading issue when it is updated during boot.
> Henrique de Moraes Holschuh wrote: > To me, so far it looks like the issue is caused by a three-way > interaction: microcode - kernel - platform/BIOS. I agree, and was not clear. I meant everything related to the actual upgrade. Issues with re-initializing after suspend, and maybe in this case, after microcode upgrade are why I have started to follow this bug report. And along those lines, and further to my post #28 and #30, I have been wondering if the CPU frequencies could be unstuck by clearing all the logged bits. Perhaps they got set inadvertently during the microcode upgrade, and not cleared as part of post upgrade re-initialization. Even though that wouldn't explain the currently active bits, it might be worth a try (as su). wrmsr 0x690 0x00 wrmsr 0x6B0 0x00 wrmsr 0x6B1 0x00 wrmsr 0x1B1 0x00 wrmsr -a 0x19c 0x00 wrmsr -a 0x19a 0x00 I may have forgotten one or more registers. The msr-tools package is required and "modprobe msr" (as su) is needed before those commands. We should look for any platform/BIOS commonality between the suffers of this issue (if the current Srinivas test doesn't work, that is). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1480349 Title: Intel Microcode Breaks frequency scaling in Xeon® E5-2687W v3 & E5-1650 v3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1480349/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
