Intel's communication is incredibly poor. Errata exist for all CPUs but this one is quite important and resulted in no proper public communication it seems.
Intel Skylake/Kaby Lake processors: broken hyper-threading
261–270 of 278 posts
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#262Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#263The latest intel-microcode package from Ubuntu 16.04 does not fix the problem. I installed the same package from Ubuntu 17.10 [0] which fixes the problem. You can check your system with the script linked in the mailing list thread [1]. [0] https://packages.ubuntu.com/en/artful/amd64/intel-microcode/... [1] https://lists.debian.org/debian-devel/2017/06/msg00309.html
How do you check if the issue is actually fixed after installing the microcode fix?
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#264The poor guys from OCaml who found the bug. Imagine how much debugging it takes to find such an issue and narrow it down to the precise register sequence. I guess since it’s a hyper threading bug it even depends on multiple threads doing certain things at the same time. Usually you trust your CPU to execute code properly.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#265One of many typical erratum... nothing to see here, been patched months ago. Most people are unlikely to ever encounter it even if unpatched.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#266Earlier quoted context omitted.
Indeed, the latest Intel microcode published for Ubuntu 16.04 is the ancient 20151106 [1]. Later Ubuntu releases do have more recent microcode packages [2]. I cannot understand why they left out 16.04 there. So much for LTS, it seems. This recently came to my attention while debugging some increasingly frequent lockups, which took me a solid week of eliminating all seemingly more likely causes (VirtualBox, nVidia dri…
> Indeed, the latest Intel microcode published for Ubuntu 16.04 is the ancient 20151106. By ancient, perhaps you mean the version that was current at the time 16.04 shipped? > I cannot understand why they left out 16.04 there. So much for LTS, it seems. See https://wiki.ubuntu.com/StableReleaseUpdates . The point of an LTS (or any stable release, for that matter) is that it doesn't change by default. For those who wa…
By ancient I mean that it is 1.7 years old and by now Intel has published 4 later releases (20160607, 20160714, 20161104 and 20170511). I think it's a fair and tame adjective considering this is processor microcode we're talking about and that it made me spend a week of my own time hunting it.
You say Ubuntu has a bug to track the microcode package as an exception, but that doesn't seem to be having a positive effect, does it? Precisely because Ubuntu cannot pick it apart, what is it that they're trying to decide in the bug? Why is Ubuntu second guessing Intel in deciding which microcode update to apply and which to skip? How would Ubuntu know that better than the manufacturer? The Intel specification updates list tons of processor bugs including some very critical ones, so we know the microcode updates do help with some of those. When was the last time that an Intel microcode update brought a new bug or made something worse? I'm not aware of any such instance, and although that may indeed happen sometime it doesn't seem as likely as facing existing known bugs, right?
I think it could be argued that it is up to the user to decide (say, a warning during installation), or that Ubuntu could choose to apply all microcode updates by default and let the user opt out. Ubuntu might impose a certain delay, say a month or two at most, in order to see if a microcode update gets withdrawn or ends up too buggy. But I don't think Ubuntu could reasonably choose to skip all microcode updates for 1.7 years like it did in my case, or to choose which ones to apply and which ones to skip, like it seems to be trying to. Microcode should be treated like other propietary software, but with special dilligence due to its criticality. If nVidia says a particular driver release is very buggy and should be updated, Ubuntu promptly updates it. Why would Ubuntu sit on known critical microcode updates then? If, and it's really a big if, eventually some microcode update brings a new bug and Ubuntu deployed it, it would be Intel's fault and not Ubuntu's.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#267If I run $grep name /proc/cpuinfo | sort -u
model name : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
then $cat /proc/cpuinfo | grep ht
Definitely there under flags Should I be concerned?
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#268Earlier quoted context omitted.
> Indeed, the latest Intel microcode published for Ubuntu 16.04 is the ancient 20151106. By ancient, perhaps you mean the version that was current at the time 16.04 shipped? > I cannot understand why they left out 16.04 there. So much for LTS, it seems. See https://wiki.ubuntu.com/StableReleaseUpdates . The point of an LTS (or any stable release, for that matter) is that it doesn't change by default. For those who wa…
By ancient I mean that it is 1.7 years old and by now Intel has published 4 later releases (20160607, 20160714, 20161104 and 20170511). I think it's a fair and tame adjective considering this is processor microcode we're talking about and that it made me spend a week of my own time hunting it. You say Ubuntu has a bug to track the microcode package as an exception, but that doesn't seem to be having a positive effect…
Why is this Ubuntu's sole responsibility? Can you not get a UEFI firmware update from your vendor?
> I think it's a fair and tame adjective considering this is processor microcode we're talking about...
Processor microcode updates haven't, to my knowledge, ever automatically been applied by distributions in the past. In light of that, I don't see how it's reasonable to have an expectation otherwise.
> You say Ubuntu has a bug to track the microcode package as an exception, but that doesn't seem to be having a positive effect, does it?
By being careful before pushing out an update to millions of users? I'd say that's a positive effect.
> ...what is it that they're trying to decide in the bug?
Whether to continue to let users have a choice, or by taking that choice away by doing things automatically for them. There are also packaging-based regressions to consider; not just the microcode ones. For example: if the wrong microcode is applied to the wrong processor because of a packaging error, who would you be blaming? Intel or Ubuntu?
> But I don't think Ubuntu could reasonably choose to skip all microcode updates for 1.7 years like it did in my case...
Ubuntu didn't "choose to skip" all microcode updates. Ubuntu didn't choose at all; pushing an update requires a specific effort.
In light of this issue, Ubuntu is now considering what to do about it, responsibly, for all users. Both for this particular issue, and for microcode updates going forward.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#269Earlier quoted context omitted.
> Indeed, the latest Intel microcode published for Ubuntu 16.04 is the ancient 20151106. By ancient, perhaps you mean the version that was current at the time 16.04 shipped? > I cannot understand why they left out 16.04 there. So much for LTS, it seems. See https://wiki.ubuntu.com/StableReleaseUpdates . The point of an LTS (or any stable release, for that matter) is that it doesn't change by default. For those who wa…
By ancient I mean that it is 1.7 years old and by now Intel has published 4 later releases (20160607, 20160714, 20161104 and 20170511). I think it's a fair and tame adjective considering this is processor microcode we're talking about and that it made me spend a week of my own time hunting it. You say Ubuntu has a bug to track the microcode package as an exception, but that doesn't seem to be having a positive effect…
> Why is Ubuntu second guessing Intel in deciding which microcode update to apply and which to skip? How would Ubuntu know that better than the manufacturer?
The whole point of an LTS release is that they will keep a stable baseline for all the packages they're distributing and apply a certain amount of integration testing. If you believe upstream knows best (and I'm not saying you're wrong to do so) then why use LTS in the first place?
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#270Earlier quoted context omitted.
By ancient I mean that it is 1.7 years old and by now Intel has published 4 later releases (20160607, 20160714, 20161104 and 20170511). I think it's a fair and tame adjective considering this is processor microcode we're talking about and that it made me spend a week of my own time hunting it. You say Ubuntu has a bug to track the microcode package as an exception, but that doesn't seem to be having a positive effect…
Why is this Ubuntu's sole responsibility? Can you not get a UEFI firmware update from your vendor? > I think it's a fair and tame adjective considering this is processor microcode we're talking about... Processor microcode updates haven't, to my knowledge, ever automatically been applied by distributions in the past. In light of that, I don't see how it's reasonable to have an expectation otherwise. > You say Ubuntu…
I don't think yours is a serious answer, what I said already refutes your points. Ubuntu has already made me waste a week and I don't want to waste any more, particularly when you can't or won't listen to what I say and look for irrelevant excuses like the availability of UEFI vendor updates. Just FYI Intel provides these updates for very good reasons and RHEL/CentOS/Fedora have been providing processor microcode updates for ages now and with relatively frequent updates (see the microcode_ctl RPM changelog). Bye now.