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

151–160 of 278 posts

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

#151

Post by CalChris »

pbsd wrote: post #124
cesarb wrote: post #75

Earlier quoted context omitted.

> 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) This is yet another of the many places where the complexity of the x86 ISA shows up and makes its hardware implementations more complicated: the x86 ISA has instructions which can modify the second -lowest byte of a register, while keeping the rest of the rest of th…

The loop needs to be short because the loopback buffer is only active in loops of 64 or fewer entries (usually fewer real instructions, something like 40 or so). Moreover, Skylake introduced one loopback buffer per thread, instead of the previous loopback buffer shared between both threads. My guess is that is where the bug is; the behavior for partial register access stalls---insert one extraneous uop to combine, e.…

Just as information, the Loop Stream Detector was introduced in Intel Core microarchitectures. With Sandy Bridge, it was 28 μops. It grows to 56 μops (with HT off) with Haswell and Broadwell. It grows again (considerably) with Skylake to 64 μops per thread (HT on or off).

The LSD resides in the BPU (branch prediction unit) and it is basically telling the BPU to stop predicting branches and just stream from the LSD. This saves energy. However, predicting is different than resolving. Branch resolution still happens and when resolution (speculation) fails, the LSD bails out.

In any case, 64 μops is a lot. That's a good sized inner loop.

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

#152

Post by dboreham »

davidmr wrote: post #65
wbl wrote: 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.

In my limited experience, their root cause analyses are really impressive as well with lots of internal attention and resources. I'm not allowed to talk about any Intel issues, but we reported a very strange issue to Nvidia, sent a couple of dozen cards back and six months later got a truly fascinating report back we with hundreds of pages of compute test result tables and electron microscope images and chemistry lab…

This is because once upon a time people were put in jail for not doing that (when the customer was the DoD).

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

#153

Post by bleair »

When intel had the floating point division hardware bug they recalled chips. https://en.wikipedia.org/wiki/Pentium_FDIV_bug

I wonder if intel will do something like that again or if the industry as a whole is more tolerant of unreliable / buggy behavior and will just live with it. Examples of Apple just telling people that the poor reception strength was their own fault / changing software to hide problems / etc.

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

#154

Post by magila »

baruch wrote: post #132
davidmr wrote: post #65

Earlier quoted context omitted.

In my limited experience, their root cause analyses are really impressive as well with lots of internal attention and resources. I'm not allowed to talk about any Intel issues, but we reported a very strange issue to Nvidia, sent a couple of dozen cards back and six months later got a truly fascinating report back we with hundreds of pages of compute test result tables and electron microscope images and chemistry lab…

I worked for a large company that used thousands of Intel CPUs every year and when we suspected a CPU bug we were mostly brushed off. We had a very persistent person on the team who kept tracking the issue to find correlations and some very good kernel developers that went on to nearly pin-point the issue and only then did Intel pay attention and it then took them still several months to acknowledge the issue give a…

Intel likely has very thorough data on the issue, but you'll never see it unless you are one of their tier 1 customers* and have an NDA with them. In my experience working for a large hardware manufacturer they are very skittish about releasing detailed failure analysis data to outside companies.

* For Intel that would be companies like Dell, Apple, HP, and maybe a couple of others.

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

#155

Post by brigade »

valarauca1 wrote: post #123
cesarb wrote: post #75

Earlier quoted context omitted.

> 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) This is yet another of the many places where the complexity of the x86 ISA shows up and makes its hardware implementations more complicated: the x86 ISA has instructions which can modify the second -lowest byte of a register, while keeping the rest of the rest of th…

You really don't know what you're talking about. --- For Skylake, they probably optimized partial register writes to these four partial "high" registers (AH, BH, CH, DH), but the optimization was buggy in some hard-to- hit corner case. They did not do this. The high registers (AH/BH/DH/CH) are nearly written out of existence with the REX Prefix in 64bit mode. Within the manual(s) it is called out effectively not to u…

> High Register and 16bit registers are huge wart that it seems Intel is trying desperately hard to get us to stop using.

Someone really ought to tell clang and gcc this; they both happily use 16-bit registers for 16-bit arithmetic.

Anyway, Intel obviously already has special optimizations for many partial register accesses, dating back to Sandy Bridge. While it's quite possible that they left out the high registers initially (no clue, don't care), if they did they could have decided to include them in Skylake. Who knows though...

What are you even talking about with the LSD? The LSD is entirely before any register renaming and the entire out-of-order bits of the CPU. It's likely the LSD is involved only because that (plus hyperthreading) might be the only way to get enough in-flight µops to trigger whatever is going wrong, whether or not it's due to optimizations for partial register accesses.

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

#156

Post by aarongolliver »

bleair wrote: post #153

When intel had the floating point division hardware bug they recalled chips. https://en.wikipedia.org/wiki/Pentium_FDIV_bug I wonder if intel will do something like that again or if the industry as a whole is more tolerant of unreliable / buggy behavior and will just live with it. Examples of Apple just telling people that the poor reception strength was their own fault / changing software to hide problems / etc.

If you read the link you'll see they've fixed it with a microcode update.

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

#157

Post by DamonHD »

skm wrote: post #128
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.

If you're on a Mac, you can find the exact processor model number by opening Terminal.app and entering sysctl -n machdep.cpu.brand_string this will return something like Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz (Found on http://osxdaily.com/2011/07/15/get-cpu-info-via-command-line... )

Exactly the same output for me. Assuming that's not the only hardwired output from that command, is your password also hunter2? B^>

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

#158

Post by [deleted] »

mjw1007 wrote: post #106
d33 wrote: post #40

Earlier quoted context omitted.

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 p…

[deleted]

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

#160

Post by theGimp »

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?

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.

Post reply on HN