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

231–240 of 278 posts

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

#231

Post by KayEss »

ploxiln wrote: post #168
esaym wrote: post #108

Earlier quoted context omitted.

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

I worry about hyperthreading hurting worst-case latency (since a thread might be assigned to run on a virtual core which does not work as fast as expected).

I've looked for this and I see little evidence that worries me (this on Linux). The kernel seems to schedule first on the real primaries and then on the secondaries within a pair, and the kernel is also not all that shy about moving a thread to a different CPU.

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

#232

Post by skrebbel »

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 would recommend demoscene productions, cracktros, and even certain malware*

Modern PC demoscene productions don't really do very funky things CPU-wise anymore. Most run mostly in shaders, actually. Amiga and C64 is a different story, but Intel isn't making that many Amiga CPUs :-)

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

#233

Post by donkeyd »

coldtea wrote: post #107
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.

I've run into an issue where switching users causes a crash on my 2016 MBP. Many more people are having this issue, according to the Google.

Also, up until the end of 2016, Apple didn't use Skylake processors, so it wouldn't be 2+ years.

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

#234

Post by matrixagent »

fotcorn wrote: post #30

The latest intel-microcode package from Ubuntu 16.04 does not fix the problem. I installed the same package from Ubuntu 17.10 [0] which fixes the problem. You can check your system with the script linked in the mailing list thread [1]. [0] https://packages.ubuntu.com/en/artful/amd64/intel-microcode/... [1] https://lists.debian.org/debian-devel/2017/06/msg00309.html

How do you install the update from that version?

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

#235

Post by wscott »

Has anyone benchmarked one of these machines before and after applying this microcode update? The options in microcode are rather limited and all are likely to have performance impacts. This is likely disabling functionally to avoid this case. I would hope the patch is smart enough to not apply if threading is not enabled, but who knows.

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

#236

Post by wolfgke »

justinclift wrote: post #72
wav-part wrote: post #51

Earlier quoted context omitted.

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

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

> 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

You know "The Animatrix - Beyond"?

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

#237

Post by protomyth »

pshc wrote: post #60
autokad wrote: post #54

Earlier quoted context omitted.

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.

The VIPER was built to be fully proven, but there was come debate on methodology.

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

#238

Post by wyager »

Confusion wrote: post #227
wyager wrote: post #220

Earlier quoted context omitted.

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

Then use a proof methodology that doesn't require exhaustive enumeration. You may as well have said "then you use a magical tool that doesn't exist". Strings also occupy a "large state space", but this obviously doesn't prevent us from doing formal verification on functions over strings. What is your reason to think this is 'obviously' the case?

> You may as well have said "then you use a magical tool that doesn't exist".

Ok, so what this tells me is that you're not aware of what modern verification techniques look like.

There's not really any one resource I can point you to, but take a look at these links. I've used these or similar technologies personally, but there are others I haven't used.

https://en.m.wikipedia.org/wiki/Intuitionistic_type_theory

https://en.m.wikipedia.org/wiki/Homotopy_type_theory

https://leanprover.github.io/about/

http://goto.ucsd.edu/~rjhala/liquid/liquid_types.pdf

> What is your reason to think this is 'obviously' the case?

Because I've done this, and anyone who claims to be familiar with formal methods should be at least passingly familiar with all the things I mentioned.

Even if you aren't, if you've ever heard of SAT (a fairly universal CS concept) you should at least be familiar with the idea that non-exhaustive proofs are a thing.

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

#239

Post by lorenzhs »

sqldba wrote: post #216
lorenzhs wrote: post #53

Earlier quoted context omitted.

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.

Seems like they do when it fixes serious bugs, a quick search yields e.g. https://support.microsoft.com/en-us/help/3064209/june-2015-i... ("This update fixes several issues with Intel CPUs that could cause computer crashes or functions incorrectly.")

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

#240

Post by lorenzhs »

ComputerGuru wrote: post #172
lorenzhs wrote: post #166

Earlier quoted context omitted.

That's just the workaround until a fix is available for your CPU, if I understood correctly.

No, that's not what I meant. In the past, Intel's microcode updates have simply disabled the broken functionality as an official solution. http://techreport.com/news/26911/errata-prompts-intel-to-dis...

You specifically said the fix might be to permanently disable HT.

The TSX situation was indeed unfortunate, I have one of the affected CPUs. But it was a new feature that was broken, not something that used to work, so the bug's impact was less serious, and disabling the feature didn't have too much of an impact.

Post reply on HN