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

101–110 of 278 posts

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

#101

Post by coldtea »

theGimp wrote: 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…

>Inexcusable

What, the "found the issue, documented it, and fixed it" part?

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

#102

Post by justinclift »

roywiggins wrote: post #93
justinclift wrote: post #72

Earlier quoted context omitted.

Hmmm... on that note, if the universe is a simulation, then a bug in that could have some interesting ramifications. "Don't use the bookshelf over there, physics is broken on that shiny spot." :D

The problem with finding a physics bug is that it's liable to be amplifiable. Break conservation laws just a little bit and suddenly you have potential for exponential runaway leading to an unplanned reality excursion, and say goodbye to your light-cone.

Well, by definition the behaviour would be undefined so could go any which way. ;)

Modern day VM software has various levels of exception checking, and code to catch/mitigate/etc when bugs crop up.

So, a universe-capable simulator might have any kind of behaviour if/when a bug occurs. It doesn't need to be an unbounded, runaway scenario. :)

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

#103

Post by justinclift »

decisiveness wrote: post #94
justinclift wrote: post #77

Earlier quoted context omitted.

Hmmm, checking for "ht" seems to be giving weird info. On a i5-750 here (few years old), running Fedora 25: $ grep '^flags.*[[:space:]]ht[[:space:]]' /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor…

It looks like dmidecode also contradicts itself with the hyper threading flag: $ sudo dmidecode -t processor | grep -E 'Flags:|HTT|Status|Count' Flags: HTT (Multi-threading) Status: Populated, Enabled Core Count: 4 Thread Count: 4

Hmmm... yeah that's showing the same on mine too. According to dmidecode, this CPU has hyperthreading.

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

#104

Post by gcb0 »

wbl wrote: post #18
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…

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.

releasing cpu micro code to work around bugs is very cheap.

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

#105

Post by coldtea »

isaac_is_goat wrote: post #79
gbin wrote: post #59

Earlier quoted context omitted.

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.

Still seems to be doing better than "turn off half of your processor, sorry no fix just buy a new one".

Actually TFA mentions there's already a fix.

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

#106

Post by mjw1007 »

d33 wrote: post #40
theGimp wrote: 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?

I don't mind Intel keeping very quiet about fixed-in-microcode bugs that don't directly affect valid userspace programs, like

« Instruction Fetch May Cause Machine Check if Page Size and Memory Type Was Changed Without Invalidation »

or

« Execution of VAESIMC or VAESKEYGENASSIST With An Illegal Value for VEX.vvvv May Produce a #NM Exception »

but something like this should be announced clearly.

(I keep my microcode packages up to date, but I don't normally bother rebooting when an update comes in.)

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

#107

Post by coldtea »

asow92 wrote: post #82

So what does this mean for the thousands of new MacBook Pro 2016/2017 owners out there?

Nothing, since they've been running their laptops without issues (it would have been all over the news if it was some widespread issue) for 2+ years.

At some point in the near future Apple will package the microcode fix in an update, and that will be it.

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

#108

Post by esaym »

Syzygies wrote: post #48

In my experience with parallel code written in Haskell, hyper-threading offers only a very mild speedup, perhaps 10%. It is essentially an illusion, a logical convenience. (How long does it take to complete a parallel task on a dedicated machine? Four cores with hyper-threading off has nearly the performance of eight virtual cores with hyper-threading on.) Many people have neither the interest nor the hardware access…

It normally helps "some", and rarely hurts performance. So you might as well enable it.

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

#109

Post by coldtea »

salex89 wrote: post #12

Great, pay a premium for the top of the line CPU to get anything more than 4 threads, that disable it...

Premium != perfect. You pay for the extra speed, cache, etc.

And since a cheaper cpu can have the same or worse bugs, the point is moot.

You don't pay i7 vs i5 etc for better quality control.

For that you have to go to enterprise/server grade stuff that costs much more (Xeon). And even there, nothing is guaranteed to be perfect.

In fact, with the complexity of modern CPUs/GPUs it's a minor miracle that anything works at all. We have it better than ever...

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

#110

Post by throwaway2048 »

coldtea wrote: post #97
throwaway2048 wrote: post #52

Earlier quoted context omitted.

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

There will always be. What then? We stop producing cpus and wait for some magical new technology that prevents all bugs?

Its why you can't treat hardware bugs and dismiss them flippantly like software ones.
Post reply on HN