Intel Skylake/Kaby Lake processors: broken hyper-threading
lists.debian.org
Intel Skylake/Kaby Lake processors: broken hyper-threading
1–10 of 278 posts
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#2Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#3Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#4Also 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.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#5So 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.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#6Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#7Problem: 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 experienced intermittent crashes etc. and just nonchalantly attributed it to something else like "buggy software" or even "cosmic ray", when it was actually a defect in the hardware. Or more importantly, how many engineers at Intel, working on these processors, saw this happen a few times and did the same.
More interestingly, I would love to read an actual detailed analysis of the problem. Was it a software-like bug in microcode e.g. neglecting some edge-case, or a hardware-level race condition related to marginal timing (that could be worked around by e.g. delaying one operation by a cycle or two)? It reminds me of bugs like https://news.ycombinator.com/item?id=11845770
This and the other rather scary post at http://danluu.com/cpu-bugs/ suggests to me that CPU manufacturers should do more regression testing, and far more of it. I would recommend demoscene productions, cracktros, and even certain malware, since they tend to exercise the hardware in ways that more "mainstream" software wouldn't come close to. ;-)
(To those wondering about ARM and other "simpler" SoCs in embedded systems etc.: They have just as much if not more hardware bugs than PCs. We don't hear about them often, since they are usually worked around in the software which is usually customised exactly for the application and doesn't change much.)
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#8Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#9Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#10So 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.
What is the percentage of non fixable chips for Skylake and kabylake? Sometimes those early steppings are not widely distributed.