** Description changed:
- When I boot with this installed frequency scaling is no longer behaving
- as expected.
+ SRU Justification Wily
+
+ CPU scaling on a class of Intel CPUs is not functioning correctly,
+ causing the CPU to be throttled back to the lowest CPU frequency
+
+ [FIX]
+
debdiff:
http://launchpadlibrarian.net/235642871/thermald_1.4.3-5_1.4.3-5ubuntu1.diff.gz
--
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
debdiff attached
** Patch added: "debdiff"
https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1480349/+attachment/4559107/+files/thermald_1.4.3-5_1.4.3-5ubuntu1.diff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Also affects: thermald (Ubuntu)
Importance: Undecided
Status: New
** Changed in: thermald (Ubuntu)
Importance: Undecided => High
** Changed in: thermald (Ubuntu)
Assignee: (unassigned) => Colin Ian King (colin-king)
** Changed in: thermald (Ubuntu)
Milestone: None =>
This bug was fixed in the package thermald - 1.4.3-6
---
thermald (1.4.3-6) unstable; urgency=medium
* Fix frequency scaling issue on specific Intel CPUs (LP: #1480349)
- roll earlier patches that allow us to cleanly patch the issue
- Error recovery when sysfs attrib read
@Colin
I want to see if there is a race condition, by changing runlevel to 5 without
any other change. What do we need to change in systemd service file?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@Srinivas,
systemd uses targets which serve a similar purpose as runlevels, to
change this on a running system one uses sysemctl
1. To list different target types use:
systemctl list-units --type=target
multi-user.target is equivalent to run level 3
graphical.target is equivalent to run level
I've uploaded a patched version of thermald that includes 4 fixes from
Srinivas and also modifies thermald to only start on runlevel 5.
Packages for wily and xenial can be found in ppa:colin-
king/thermald-1480349 - please install and test to see if it fixes the
issues
sudo add-apt-repository
I just tested the version of thermald in the PPA and my now computer is
functioning as expected.
--
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
Hi folks, I'd appreciate some more testing on this before I proceed any
further with the fixes. If one can test the packages in my ppa (see
comment #60) and let me know:
release (wily or xenial)
passed or failed.
Thanks.
--
You received this bug notification because you are a member of Ubuntu
I up still not sure about the root cause. Can anybody help on collecting
startup logs (journalctl -b)?
Can we just change runlevel to 5 and see if the problem is fixed.If there is a
race condition in loading then this should address this.
@Colin, What changes are required to run at run level 5?
@Srinivas,
I changed the run level to 5 in this updated package, so it should do
this automatically when the update is installed.
--
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
I wonder if these MSRs are set to the same contents in *all* cores?
Anyway, please look at this:
http://article.gmane.org/gmane.linux.power-
management.general/70615/match=msr_ia32_energy_perf_bias
"The assumption that BIOSes never want to have this register being set to
full performance
@hmh, does this require compiling a kernel? Last time I did that was
some 8 years ago, on Debian.
--
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
Very strange. From the logs thermald didn't take any action. Then also the
problem seems to be fixed.
Can you let thermald run for few minutes in the same way and collect logs?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
oh, you *do* need a kernel source tarball, or a fresh clone from git if
you want to compile the tool.
--
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
No, I think you can just go to that directory and type Make.
You can also use wrmsr (make sure to write to *all* cores).
--
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
I am also affected on my haswell-ep i7-5820k desktop. After disabling
thermald performance is back to normal.
--
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
I think it has to do with the starting of thermald too early while driver
modules are not ready.
@Chris:
Can you attach thermald logs (when started by systemd) and also by disabling
and started by command line?
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Currently systemd runlevels are [2345], can we try just [5]
In the systemd service file. thermald.conf
change
start on runlevel [2345] and started dbus
to
start on runlevel [5] and started dbus
If thermald is loading too early, then this will delay till run level 5.
--
You received this bug
@hmh, `$ sudo rdmsr 0x1b0` returned `7`.
--
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
I've:
1. Installed `intel-microcode`
2. Rebooted
I did this to make sure that the problem still exists. And it did. Then
I:
3. `sudo systemctl disable thermald`
4. Rebooted
Frequency scaling seems fine. Hooray!
Attached is output of commands requested in #47.
** Attachment added: "output of
Would testing with 15.10 help or have we figured this out?
--
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
Can you also check MSR_IA32_ENERGY_PERF_BIAS (MSR 0x1b0) ?
--
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
FWIW, regarding platform commonality: We saw this after pushing the
microcode update on two HP z440 workstations, one in Munich and one in
Tokyo. Specifically both were E5-1650 v3.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@Shahar
Also if #43 solves your issue, can you do following steps
cd /sys/class/powercap
grep -r . *
cd /sys/class/thermal
grep -r . *
cd /sys/class/hwmon
grep -r . *
sudo ./thermald --no-daemon --loglevel=debug
I am thinking a combination of factors is causing this issue. First of all this
On Thu, Jan 21, 2016, at 03:18, Doug Smythies wrote:
> @Philipp: The way I read them, your comment #35 and your comment #27
> contradict each other.
>
> @Xiong: The way I read all of this stuff, it has not been proven that
> the issue is in the microcode itself. However, the work done by Sharar
>
ALthough it was tried before:
"
Shahar Or (mightyiam) wrote on 2015-07-31:
`$ sudo systemctl stop thermald` doesn't seem to change it.
"
Can we try by deleting the service to avoid any throttling might have occurred
during boot?
This is a Xeon server, don't need thermald.
--
You received this
@Intel, my affected system is up for sale if you want it.
--
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
@srinivas-pandruvada
If I understand you correctly, the steps are:
1. Install the intel-microcode package
2. `sudo systemctl disable thermald`
3. Reboot
4. See whether frequency scaling is broken
Is this correct?
--
You received this bug notification because you are a member of Ubuntu
Bugs,
>> 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:
@Shahar
I thought you already have a system with upgraded microcode. If this is not too
much trouble. then please try the steps you outlined in #43 (previous comment).
I am still not clear is that
- For the same kernel version and ubuntu 15.10, if you just upgrade
micro-code, does it breaks
Thanks for all of the churn on this. Please tell me if I can help in any
way.
--
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
Hi Shahar,
Can you quickly try steps suggested in #38? You can do "sudo systemctl disable
thermald" and then reboot.
--
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
FYI - Intel is trying to reproduce and debug this issue in the US.
--
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 &
@Philipp: The way I read them, your comment #35 and your comment #27
contradict each other.
@Xiong: The way I read all of this stuff, it has not been proven that
the issue is in the microcode itself. However, the work done by Sharar
in earlier postings, in my opinion, narrows it down to either
0x2b is known good for me, 0x36 known bad.
--
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
For users with this problem on E5-1650 v3, Intel requested the
model:stepping info from /proc/cpuinfo, so please paste the
/proc/cpuinfo into the bug report. Thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@Colin: Gabor (from the duplicate) and Shahar (from the turbostat
postings) both have: family : 6 ; model : 63 ; stepping : 2 also.
--
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:
processor : 11
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
stepping: 2
microcode : 0x2b
cpu MHz : 1233.339
cache size : 15360 KB
physical id : 0
siblings: 12
core id
@Philipp & @Doug:
I couldn't reproduce your issue on my E5-2697 v3 platform with 0x2B and 0x36
microcode in Ubuntu 16.04. E5-2697 v3 has the same F/M/S with the affected
processor E5-1650 v3 and E5-2687W v3.
Could you tell me what's your conclusion that it is a microcode regression or
I could try briefly next week, but from what I recall from my December
attempts setting intel_pstate=0 on the kernel's cmdline did *not* help.
I saw a different frequency in cpuinfo (1.2 GHz), but the machine was
still incredibly slow.
--
You received this bug notification because you are a
When using the acpi-cpufreq driver, "/proc/cpuinfo" shows the frequency that is
being asked for, not the frequency one actually gets.
One has to use turbostat to know for sure.
For whatever reason, and as mentioned in my previous post, the posted
turbostat output is saying that excessive power
So for E5-1650 v3 specifically:
0x2b works (microcode in trusty). 0x36 works with 3.13, but not with
either 3.19 nor 4.3. (Pointing at intel_pstate, I think.)
** Changed in: intel-microcode (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a
As Kristen mentions in post 18, the CORE_PERF_LIMIT_REASONS MSR is
saying that the frequency is reduced below the operating system request
due to PBM (Power Budget Management) limit. It seems odd that in such a
reduced power consumption state the bit is still asserted.
Note that whenever the
Thank you for letting me know of the update, Colin. I've upgraded to
Xenial and installed intel-microcode (3.20151106.1) and seemingly no
change on this issue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Summary changed:
- Breaks frequency scaling in Xeon® E5-2687W v3 & E5-1650 v3
+ Intel Microcode Breaks frequency scaling in Xeon® E5-2687W v3 & E5-1650 v3
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
intel-microcode (3.20151106.1) was recently sync'd into Ubuntu Xenial,
see: http://packages.ubuntu.com/xenial/intel-microcode
It may be worth checking to see if this resolves the issues for you.
** Changed in: intel-microcode (Ubuntu)
Status: In Progress => Incomplete
--
You received
48 matches
Mail list logo
