Live data from Hacker News

Intel Skylake/Kaby Lake processors: broken hyper-threading

lists.debian.org

11–20 of 278 posts

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

#13
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.

It sounds like they can all be fixed by disabling hyperthreading.

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

#17

Holy cow. Definitely feel like I dodged a bullet by building an AMD/Ryzen system this time around - which had it's own set of issues (but seem to be more or less ironed out now).

I don't think Ryzen has had any more or less bugs than the recent Intel generation. They are at least on the same order of magnitude.

Ryzen is great, I might buy one next, but it is not to "doge bullets".

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

#18

The problem description is short and scary: Problem: Under complex micro-architectural conditions, short loops of less than 64 instructions that use AH, BH, CH or DH registers as well as their corresponding wider register (e.g. RAX, EAX or AX for AH) may cause unpredictable system behavior. This can only happen when both logical processors on the same physical processor are active. I wonder how many users have experi…

CPU manufacturers do do huge amounts of testing, and Intel does formal verification of some functional units. The reliability is far better than most software, in part because making a new release costs billions.

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

#19
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.

Sounds like they can be fixed by the patch isn't out yet?
Post reply on HN