Live data from Hacker News

Intel Skylake/Kaby Lake processors: broken hyper-threading

lists.debian.org

31–40 of 278 posts

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

#31
There's a perl script on the debian mailing list that digs a bit deeper and tells you if you're affected in the first place, if you're affected but patched already, affected but have HT disabled, etc.

https://lists.debian.org/debian-user/2017/06/msg01011.html

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

#32
post #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.

It may be far better than average software quality but far more also relies on it. The question is whether the quality is adequate in light of what is at stake.

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

#33
post #29
post #18

Earlier quoted context omitted.

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.

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…

So it's okay for software to have bugs that get fixed (I think everybody here acknowledges that software will always have bugs), but Intel isn't allowed to have issues in their processors, even if they can fix them with a software (microcode) update?

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

#34
post #18

Earlier quoted context omitted.

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.

It may be far better than average software quality but far more also relies on it. The question is whether the quality is adequate in light of what is at stake.

Really? How is it different from a kernel bug that causes random behaviour? Both apparently can be fixed with a software update. They're both bad, but why should Intel be held to a higher standard if mitigation is similarly complex?

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

#35

Well, at least Intel acknowledges, documents and finally fixes these CPU bugs (via microcode updates). AMD on the other hand doesn't even acknowledge an issue when multiple customers report problems. See this Ryzen bug: https://community.amd.com/thread/215773

>at least Intel acknowledges

Not in this case.

"Apparently, Intel had indeed found the issue, documented it (see below) and fixed it. There was no direct feedback to the OCaml people, so they only found about it later."

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

#36
post #2

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

If they don't fix for Windows then they are killing 90% of their customers which they won't. So if it's not already out it will be soon. It is Linux which gets fixes late most of the time.

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

#37

Earlier quoted context omitted.

I was for a while there. Heisenban?

What makes you think you were?

Couldn't see multiple comments I made in unrelated threads when reading from an incognito tab. Unless comment delay for non logged in viewers is an undocumented feature?

Or this is inception level hellban, where some bots and devil curators lurk. What is even real.

Btw good to see your Lego contraption article in IEEE Spectrum.

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

#38

Am I hellbanned?

Off topic questions are likely to get downvotes which is probably not what you want when asking that question. You might be better served with short but relevant comments, possibly highlighting an interesting element from the article.

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

#39
post #24

The issue was being investigated by the OCaml community since 2017-01-06, with reports of malfunctions going at least as far back as Q2 2016. It was narrowed down to Skylake with hyper-threading, which is a strong indicative of a processor defect. Intel was contacted about it, but did not provide further feedback as far as we know. Fast-forward a few months, and Mark Shinwell noticed the mention of a possible fix for…

They forgot to follow up on a support ticket. As your quotation mentions, the issue was documented and fixed. Calling that "inexcusable" is a bit strong, don't you think?

I'm not a particularly big fan of Intel's practices, but the reactions in this thread seem a bit too strong to me.

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

#40
post #24

The issue was being investigated by the OCaml community since 2017-01-06, with reports of malfunctions going at least as far back as Q2 2016. It was narrowed down to Skylake with hyper-threading, which is a strong indicative of a processor defect. Intel was contacted about it, but did not provide further feedback as far as we know. Fast-forward a few months, and Mark Shinwell noticed the mention of a possible fix for…

What exactly do you find inexcusable here?
Post reply on HN