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

161–170 of 278 posts

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

#161

Post by a3_nm »

dooglius wrote: post #13
rwmj wrote: post #4

So if I understand correctly, some affected processors can be fixed by a microcode update, but there are some which cannot be fixed at all? Also the advisory seems to imply that the OCaml compiler uses gcc for code generation, which it does not -- it generates assembly directly, only using gcc as a front end to the linker.

It sounds like they can all be fixed by disabling hyperthreading.

Assuming the BIOS/UEFI has an option for it... my laptop doesn't seem to have one (and there are no updates to fix the bug either...).

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

#162

Post by arde »

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

Indeed, the latest Intel microcode published for Ubuntu 16.04 is the ancient 20151106 [1]. Later Ubuntu releases do have more recent microcode packages [2]. I cannot understand why they left out 16.04 there. So much for LTS, it seems.

This recently came to my attention while debugging some increasingly frequent lockups, which took me a solid week of eliminating all seemingly more likely causes (VirtualBox, nVidia driver, faulty RAM, etc). In the end I found the culprit while digging into the Intel Specification updates: my Core i7-5820K (and most other Haswell-E and Broadwell processors) has a bug when leaving package C-states, and the only workaround is to disable C-states above level 1. Timely updated microcode, which applies this workaround, would have saved me my week.

[1] https://launchpad.net/ubuntu/xenial/+source/intel-microcode [2] https://launchpad.net/ubuntu/+source/intel-microcode/+change...

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

#163

Post by wbl »

justsid wrote: post #99
ploxiln wrote: post #73

Earlier quoted context omitted.

That's absolutely true. When it comes to CPU/memory, skilled software engineers always think, "it must be my bug, it always is". So in that super rare case of actually running into a CPU defect, it's a mindfuck, it'll drive you crazy. You'll be looking for the flaw in your algorithm which makes it fail once a week under production load. But you just can't find it, it makes no sense ... (When it comes to drivers for n…

Similarly: Kernel bugs! Once upon a time I spend a good week trying to reproduce a rare crash one of our users saw ever so often (just enough to get our attention, but not enough to get a repro case). Stack traces made no sense and just in general the whole crash made no sense the more I looked at it. Turns out it was a bug in XNUs pthread subsystem, a part where I would have never looked if it weren‘t for desperatio…

Emacs would regularly panic the kernel on one OS X version when I opened preview to look at a pdf and had TeX recompile.

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

#164

Post by jldugger »

ereyes01 wrote: post #144
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…

A few past lives ago, I used to work on the AIX kernel at IBM. I once spent a few weeks poring through trace data trying to investigate a very mysterious cache-aligned memory corruption induced by a memory stress test. Our trace data was quite comprehensive, and is always turned on due to its very low overhead. It was concerning enough (and took me long enough) that it eventually sucked in the rest of my team to aid…

Did you by chance see the paper a year back or so outlining that memory errors are more likely to occur near page boundaries? The author's premise was that a lot of 'cosmic rays' are just manufacturing flaws.

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

#165

Post by qb45 »

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 wonder how many users have experienced intermittent crashes

I wonder if it's exploitable ;) Maybe that's why they never release the details of these CPU bugs.

> Was it a software-like bug in microcode e.g. neglecting some edge-case, or a hardware-level race condition related to marginal timing

Not sure about microcode, these x86 cores execute many simple operations natively, by means of dedicated circuits. Microcode is only involved in emulation of complex x86 instructions.

And hardware problem doesn't have to be marginal timing. It could simply be a logic bug, i.e. the circuit operates as designed but it was designed to do something else than it should be doing in some unforeseen circumstances.

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

#166

Post by lorenzhs »

ComputerGuru wrote: post #131
lorenzhs wrote: post #33

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?

If this "fix" ends up disabling HT, how can I get a refund not just for the CPU but for the $3k laptop I spec'd around it? Without needing to sue?

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

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

#168

Post by ploxiln »

esaym wrote: post #108
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.

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

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

#169

Post by brianwawok »

ComputerGuru wrote: post #131
lorenzhs wrote: post #33

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?

If this "fix" ends up disabling HT, how can I get a refund not just for the CPU but for the $3k laptop I spec'd around it? Without needing to sue?

Contact your laptop OEM.

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

#170

Post by cJ0th »

This is just great! Just yesterday I got a new laptop with a skylake processor. Now I wonder whether I experienced that bug today as I got kicked out of dosbox (on debian) for no apparent reason. In the config file I had to change the value of 'core' in the cpu-section from 'automatic' to 'normal'. Could be something entirely different but it is a funny timing.
Post reply on HN