Live data from Hacker News

Intel Skylake/Kaby Lake processors: broken hyper-threading

lists.debian.org

51–60 of 278 posts

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

#51

Earlier quoted context omitted.

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?

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

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

#52
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…

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?

There are hardware bugs that are impossible to fix in microcode. What then?

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

#53

Earlier quoted context omitted.

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?

In general, people expect hardware to be far more bug-free than all the software which depends on it. I'm disgusted enough at the current trend of continuously releasing half-baked software and "updating" it to fix some of the bugs (while introducing new bugs in the process); and yet it seems to be spreading to hardware too. From the perspective of formal verification, buggy hardware is like an incorrect axiom. but I…

Expectations of hardware are indeed higher than for software, but isn't it a valid trade-off for Intel to make as long as most of the issues can be fixed with a microcode update? On Windows, it's updated via Windows Update, and on most Linux distributions, a package exists for CPU microcode. Most users have an easy—if not automatic—way to obtain the updates.

I believe the main issue with formally verifying everything is that reasoning about parallel code is extremely hard and might well make the entire endeavour unattainable. It would be great to have formally verified CPUs, though.

> They could've caught and fixed this one with some more testing, before actually releasing.

Isn't this true of any bug?

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

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

i am more willing to accept software having bugs / failing. i have 0 tolerance for hardware to have bugs

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

#55

Earlier quoted context omitted.

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?

It's funny, since many of today's software bugs are due to the legacy of C, faults of which can often times be attributed to mimicking the behaviour CPU hardware too closely. EDIT: My wording was poor, but what I meant was that it's not like hardware vendors do not make bugs happen due to deficiencies in their design, which are not only tolerated, but often reflected in software, which runs counter to OP saying that…

Go back to rust-land now :D

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

#56
post #54
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.

i am more willing to accept software having bugs / failing. i have 0 tolerance for hardware to have bugs

nobody has, but it ain't easy.

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

#57

Earlier quoted context omitted.

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?

There are hardware bugs that are impossible to fix in microcode. What then?

you make workarounds in software, obviously.

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

#58

Earlier quoted context omitted.

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?

In general, people expect hardware to be far more bug-free than all the software which depends on it. I'm disgusted enough at the current trend of continuously releasing half-baked software and "updating" it to fix some of the bugs (while introducing new bugs in the process); and yet it seems to be spreading to hardware too. From the perspective of formal verification, buggy hardware is like an incorrect axiom. but I…

Formal verification cannot be used to fully verify an entire Intel CPU, simply because the computational resources required to do so are astronomical. Heck, the cache coherence unit alone is basically impossible to verify.

Therefore, CPU designers verify the important units (e.g., the ALU) independently of each other, and then try to verify their interaction. But a system level design verification check is simply not possible.

Obviously, faults that result from fabrication can still take place, so they are tested for using BIST and JTAG. Test coverage can be pretty high, but obviously not 100%.

As you can see, there are still a ton of places where hardware errors can seep through.

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

#59

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).

This is not a fair comment: Ryzen had a crash that can be triggered by compiling with GCC and a memory compatibility issue where it cannot run them at their nominal speed. Ryzen is a really young architecture, it already had like 6 stable patches of microcode and you can expect way more.

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

#60
post #54
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.

i am more willing to accept software having bugs / failing. i have 0 tolerance for hardware to have bugs

I wonder if there's a CPU out there that doesn't have bugs.
Post reply on HN