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

211–220 of 278 posts

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

#211

Post by codezero »

yborg wrote: post #84
ourcat wrote: post #11

So will this be affecting most Macbook Pros of the past few years? If so, there's a way to disable hyper-threading, but you need Xcode (Instruments). Open Instruments. Go to Preferences. Choose 'CPU'. Uncheck "Hardware Multi-Threading". Rebooting will reset it.

This is kind of like cutting off your leg because of a hangnail. I've been running a Skylake MBP for more than 6 months for compilation workloads and haven't seen a single processor hang. I'm much more annoyed by the completely unpredictable desktop assignment on monitors when hotplugging DisplayPort connections on multiple displays. This one bothers me every day.

That's weird re monitor issues. I've been impressed with how consistent mine are.

What I see:

Same monitor/monitors plugged into same ports produce consistent configs.

I get a unique config per monitor/port.

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

#212

Post by Laforet »

gbin wrote: post #59
isaac_is_goat wrote: post #8

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.

Is there any published errata for Ryzen or other family 17h CPUs?

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

#213

Post by wyldfire »

theGimp wrote: post #160
d33 wrote: post #40

Earlier quoted context omitted.

What exactly do you find inexcusable here?

The contempt for users. I know what I do when a user files a real bug: respond to them, acknowledge it's a problem, tell them when it's fixed. The fact that Intel does not do that with a bug of this magnitude shows how much respect they have for their users.

It's totally plausible that Intel detected this bug independently with their own verification effort or through another customer. Matching different defect reports when "unexplained" or nondeterministic behavior is the expected result can be challenging.

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

#214

Post by ibic »

userbinator wrote: post #7

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…

I've no knowledge about IC design, but it sounds to me that even the biggest name in CPU industry doesn't (or do they ever) do formal verification? Is the process like when I'm writing some mediocre code and say to myself: "hmm, it probably works", and throw the bunch into the version control (whereas they throw it to the wafer fab)?

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

#215

Post by sqldba »

lorenzhs wrote: post #33
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…

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 would be nice if they allowed users to update rather than vendors. I have a mobile Xeon. I don't know if it's affected or not.

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

#216

Post by sqldba »

lorenzhs wrote: post #53
userbinator wrote: post #42

Earlier quoted context omitted.

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…

Windows update applies CPU patches?!

I know they did AMT but that was a special case and different.

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

#217

Post by hueving »

theGimp wrote: post #160
d33 wrote: post #40

Earlier quoted context omitted.

What exactly do you find inexcusable here?

The contempt for users. I know what I do when a user files a real bug: respond to them, acknowledge it's a problem, tell them when it's fixed. The fact that Intel does not do that with a bug of this magnitude shows how much respect they have for their users.

'Contempt' is far too dramatic of a word. I think what you mean is 'indifference'.

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

#218

Post by sqldba »

coldtea wrote: post #100
autokad wrote: post #90

Earlier quoted context omitted.

stop playing lawyer ball. i'm talking about the bugs that require turning off core functionality (such as hyperthreading) and/or that lead to system halts / corrupted data. yes it happens, but software bugs happen every day where as if your system blue screened every day you know dang well you'd be on the phone with the hardware vendor for a refund / new system.

> yes it happens, but software bugs happen every day where as if your system blue screened every day you know dang well you'd be on the phone with the hardware vendor for a refund / new system. Well, since hundreds of millions of people use Skylake/Kaby Lake CPUs for 2 years now, and only now we learn about this, obviously this is not of the "system blue screens every day" variety but a very rare bug.

> obviously this is not of the "system blue screens every day" variety but a very rare bug

Not to be anal but we can't know this.

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

#219

Post by tempestn »

aarongolliver wrote: post #188
joshschreuder wrote: post #180

How does one get new microcode on Windows? Is that what the Intel Chipset drivers are? And is the microcode fix available for non-Linux systems yet?

Windows update

Has this already been patched via Windows Update? I didn't even know WU could do CPU microcode patches.

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

#220

Post by wyager »

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…

> 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 formal verification tool.

Then use a proof methodology that doesn't require exhaustive enumeration. This objection is actually fairly alarming to me; perhaps there is a larger disconnect between industrial formal techniques for hardware and software than I thought. Strings also occupy a "large state space", but this obviously doesn't prevent us from doing formal verification on functions over strings.

Post reply on HN