Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Skylake/Kaby Lake processors: broken hyper-threading

lists.debian.org

Post reply on HN
Print view View original

241–250 of 278 posts

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#241

Post by krylon »

justinclift wrote: post #72
wav-part wrote: post #51

Earlier quoted context omitted.

Because futher down the stack, more reliable a tech has to be. Otherwise good luck debugging. Also agree with heisenbit.

Hmmm... on that note, if the universe is a simulation, then a bug in that could have some interesting ramifications. "Don't use the bookshelf over there, physics is broken on that shiny spot." :D

// FIXME Trying to read both the position and the momentum of a particle reliably crashes the simulation.

// Workaround: Make the accessor method return fuzzy values for either of those values.

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#243

Post by sqldba »

paulddraper wrote: post #207
ComputerGuru wrote: post #134

So, serious question: If the microcode "fix" for this ends up disabling HT, how does one get a refund not just for the CPU but for the $3k laptop I spec'd around it? Without needing to sue? This isn't a hypothetical; what did Intel do when the only fix for broken functionality was to disable TSX entirely?

The same for any part of your computer, I imagine. What happens when your laptop's display has frequently broken pixels?

> What happens when your laptop's display has frequently broken pixels?

Well they wait for 6 or more before they say it's out of spec

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#244

Post by sqldba »

pbsd wrote: post #50
riledhel wrote: post #2

Does Windows have a patch for this too? Or just disabling HT is the safest option?

Windows does have a microcode update driver, as you would expect, so it can fix this. However, looking at the microcode update driver on an updated Windows 10 as of right now, I don't see a recent enough microcode version to fix it. The latest updates appear to be from 2015.

That's pretty cool, I didn't know of this functionality. Is there a good resource on how to look it up?

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#245

Post by RaleyField »

Syzygies wrote: post #48

In my experience with parallel code written in Haskell, hyper-threading offers only a very mild speedup, perhaps 10%. It is essentially an illusion, a logical convenience. (How long does it take to complete a parallel task on a dedicated machine? Four cores with hyper-threading off has nearly the performance of eight virtual cores with hyper-threading on.) Many people have neither the interest nor the hardware access…

>It is essentially an illusion, a logical convenience.

Just checked numbers. That was my expectation as well until I came across code that experienced a bit over 80% speedup when HT was used.

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#246

Post by tom_mellior »

rwmj wrote: post #4

So if I understand correctly, some affected processors can be fixed by a microcode update, but there are some which cannot be fixed at all? Also the advisory seems to imply that the OCaml compiler uses gcc for code generation, which it does not -- it generates assembly directly, only using gcc as a front end to the linker.

> advisory seems to imply that the OCaml compiler uses gcc for code generation, which it does not -- it generates assembly directly

Yes, but that assembly code contains calls into the OCaml runtime, for garbage collection etc. If I understand correctly, the particular loop affected by this bug was somewhere in this memory management code. That code is written in C and compiled with a C compiler.

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#247

Post by tom_mellior »

rwmj wrote: post #44
walterbell wrote: post #9

Does this affect execution of Ocaml runtime, or only the Ocaml compiler?

It affects code generated by the OCaml native compiler, which includes the OCaml compiler itself since it is written in OCaml. See also: https://caml.inria.fr/mantis/view.php?id=7452 It also affects code generated by GCC, but apparently GCC is less likely to generate code sequences which trigger the CPU bug.

> It affects code generated by the OCaml native compiler

Possibly, but that was not the issue here. It's clear from your own link that the crashes were due to C code in the OCaml runtime (used by the compiler itself), which is written in C and was compiled with GCC at -O2. See https://caml.inria.fr/mantis/view.php?id=7452#c17129

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#248

Post by rlpb »

arde wrote: post #162
fotcorn wrote: post #30

The 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

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 want to keep everything up-to-date, Ubuntu ships a new release on a six month cadence. If you choose not to use that, then you shouldn't be surprised when things aren't updated, since that's exactly what you opted in to.

The microcode package may warrant an exception, however, and we have a bug to track that. It's tricky because without the source we cannot pick apart what changed, or determine whether any changes meet our update policy. We have to be careful. Sooner or later some user will inevitably come along to tell us that a microcode update broke things, and ask why we didn't fulfill our LTS promise by not changing it.

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#249

Post by jlouis »

laydn wrote: post #135
wyager wrote: post #29

Earlier quoted context omitted.

This seems like precisely the sort of thing that a competent manufacturer should rule out formally. Formal verification of individual FUs isn't exactly ambitious... I think we're getting to levels of complexity where the process Intel uses, with lots of different QA and testing teams doing their best to look for bugs, just isn't going to cut it. We need formally verified models transformed step-by-verified-step all t…

I've done formal verification on several units of a microprocessor, and I can assure you, formal verification on individual FUs is very, very ambitious (think impossible) for a modern microprocessor. For example, you can not possibly formally verify the fetcher unit on its own, because the state space that you need to cover for several cycles for all the module inputs and outputs is beyond the capability of any forma…

I've had great success (in software) with randomized/probability based testing. You don't walk the full state space but generate subsets randomly to walk.

If done naively, it doesn't work because you are unlikely to hit the problematic bug. So you have to be clever: do not generate inputs uniformly! Generate those inputs which are really really nasty all the time. If you find a problem, then gradually simplify the case until you have reduced the complexity to something which can be understood.

With some experience for where former bugs tend to live, I've been able to remove lots of bugs from my software in edge cases via this method. (See "QuickCheck").

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#250

Post by pbsd »

sqldba wrote: post #244
pbsd wrote: post #50

Earlier quoted context omitted.

Windows does have a microcode update driver, as you would expect, so it can fix this. However, looking at the microcode update driver on an updated Windows 10 as of right now, I don't see a recent enough microcode version to fix it. The latest updates appear to be from 2015.

That's pretty cool, I didn't know of this functionality. Is there a good resource on how to look it up?

I haven't seen a description of it anywhere that I can think of. The driver lives in C:\Windows\system32\mcupdate_{genuineintel,authenticamd}.dll. All it does is detect which CPU it's running on, and load the appropriate microcode.

Loading the microcode is straightforward---all you need to do is put a few values in the appropriate MSRs. This is described in the Intel manuals, Volume 3. The microcode itself is embedded in the above DLLs, as a big binary table. The latest entry I see is 20150812 for the Intel 0x40651, aka Haswell.

Post reply on HN