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

221–230 of 278 posts

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

#221

Post by wyager »

bsder wrote: post #174
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…

Formal verification of a decode unit simply will never happen. The complexity is far too high. Formally verifying something like a multiplier block is difficult but doable if you care. Formally verifying an FPU is probably at about the limit. If you want formal verification, you would have to simplify a modern microprocessor a lot.

That's the whole point of doing a provably correct transformation from a simpler model domain. Even complicated OOOE engines are fairly tractable if you don't try to implement them at an RTL level...

Perhaps we are imagining different formal verification methodologies. Can you tell me what kind of formal verification you're referring to?

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

#222

Post by kev009 »

ereyes01 wrote: post #201
jldugger wrote: post #164

Earlier quoted context omitted.

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.

I debugged lots of memory corruption errors in my time working on AIX kernel stuff. Most of the ones I got to work on did indeed happen at a page boundary [1]. I think there is a pretty simple reason for this: "pages" are both the logical unit size of memory the kernel's allocator hands out, and the unit size that the hardware is capable of addressing in most cases. Therefore, when something at the kernel level is do…

Pretty cool to read these stories about AIX. It's always been a nice system paired with HW often a couple years ahead of the performance curve, but it certainly became more and more of a sustaining effort after 2001.

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

#224

Post by toolslive »

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…

We had been seeing this one on and off on some of our machines, and were already at least mentally pointing the finger to the LWT library. Turns out these machines were affected. That's one less worry.

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

#226

Post by matt4077 »

nol13 wrote: post #192
jldugger wrote: post #164

Earlier quoted context omitted.

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.

having often attributed these things to cosmic rays as well, anyone have any actual estimates on how often/likely cosmic rays are to cause errors in desktop-like setups? had to have been a cosmic ray at least once right?

There are some numbers in http://media.blackhat.com/bh-us-11/Dinaburg/BH_US_11_Dinabur...

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

#227

Post by Confusion »

wyager wrote: post #220
laydn wrote: post #135

Earlier quoted context omitted.

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 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?

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

#228

Post by paines »

I have a Skylake mobile CPU (i7-6700hq) and it pretty much rocks with Ubuntu 17. Also the system is stable and fast. Under heavy load, e.g. games the system is stable. Compiling a big(>10000 modules) C++ project via ninja/cmake under Qt Creator hangs the system resporducibly after ~15 minutes. I wonder now if this broken hyperthreading could be such sideffect.

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

#229

Post by deefcee »

rsynnott wrote: post #147
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.

From one of the 2016 MacBook Pros: > machdep.cpu.model: 78 > ... > machdep.cpu.stepping: 3 > ... > machdep.cpu.microcode_version: 174 Can't find if 174 is the fixed version or not. So this is one of the models for which there exists a fix, as per the email.

I'd also like to know if 78 is the fixed version.

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

#230

Post by herpderperator »

If anyone on Windows wishes to update their CPU microcode without waiting for Microsoft to push it out via Windows Update, you can use this tool from VMware https://labs.vmware.com/flings/vmware-cpu-microcode-update-d... which can update microcode as well.

Windows stores its microcode in C:\Windows\System32\mcupdate_GenuineIntel.dll which is a proprietary binary file and you can't simply replace it with Intel's microcode.dat file (which is ASCII text), so you have to use a third-party tool such as VMware's one.

Simply: 1. Download and extract the zip file in the first paragraph 2. Modify the install.bat file so that the line which reads `for %%i IN (microcode.dat microcode_amd.bin microcode_amd_fam15h.bin) DO (` only contains the microcode.dat parameter (since you obviously don't have an AMD CPU, and the tool is made for both) 3. Download and extract microcode.dat from Intel's website (https://downloadcenter.intel.com/download/26798/Linux-Proces...) and place it into the same directory as the VMware tool 4. Run install.bat with admin privileges 5. Hit cancel when it tells you that the AMD microcode files are missing, and you're done

The CPU microcode will be updated immediately (yes, while Windows is running.) The service will also run on each boot and update your CPU microcode, since microcode updates are only temporary and are lost each time you restart. You can check Event Viewer for entries from `cpumcupdate` to see what it has done. It's advised to run a tool to view the microcode version before installing (such as HWiINFO64) so you can re-run the tool after installing and confirming that the version has changed.

I have done this and it works as described. I went from 0x74 to 0xba as shown by the μCU field in HWiNFO64, and I have an i7-6700k.

Post reply on HN