• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

Intel Kabylake and Skylake CPUs have microcode bug - disable hyperthreading now!

Cromulent

Cromulent

Cromulent

Soldato
Joined
1 Nov 2007
Posts
6,445
Location
England
So it appears that Intel Skylake and Kabylake CPUs have a microcode bug that can cause data corruption and data loss when hyperthreading is enabled. Users are advised to disable hyperthreading immediately until a BIOS / UEFI fix has been released. This effects all operating systems that use these CPUs including Windows, Linux and I assume Mac OS X.

https://www.theregister.co.uk/2017/06/25/intel_skylake_kaby_lake_microcode_bug/
 
It only affects a system that does not have a software or BIOS patch in place and looking at the article, in order to trigger the bug you really need to be running a very specific scenario.

If the bug was a big problem it would have been found much sooner.
 
Wasn't there an issue with kaby lake suddenly getting very hot in some workloads? Was this ever seen on Skylake as well? I wonder if the two are related..
 
Cromulent said:
This is the post on the Debian mailing list and is much more useful as it gets into the technical aspects of the bug. It is also much more trustworthy.

https://lists.debian.org/debian-devel/2017/06/msg00308.html
Click to expand...

This is a good source. Apparently credit goes to the OCaml community, they've been seeing this for about a year.

Also check out the hackernews comments, some very knowledgable people in there.

https://news.ycombinator.com/item?id=14630183

In particular this from "cesarb"

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 the register unmodified (but AFAIK no instructions which do the same for the third-lowest byte, showing its lack of orthogonality).

For in-order implementations, like the ones which originated the x86 ISA, it's not much of a problem. But for out-of-order implementations, which do register renaming, partial register updates are harder to implement, since the output value depends on both the output of the instruction and the previous value of the register. The simplest implementation would be to make a instruction depending on the new value wait until it's committed to the physical register file or equivalent, and that's probably how it was done for these instructions for these partial registers before Skylake.

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. That corner case probably can only be reached when some part of the out-of-order pipeline is completely full, which is why it needs a short loop (so the decoder is not the bottleneck, AFAIK there's a small u-op cache after the decoder) and two threads in the same core (one thread is probably not enough to use up all the resources of a single core). The microcode fix is probably "just" flipping a few bits to disable that optimization.

And this shows how a ISA is more than just the decoding stage; design decisions can affect every part of the core. In this case, if your ISA does not have partial register updates (usually by always zero-extending or sign-extending when writing to only part of a register, instead of preserving the non-overwritten parts of the previous value), you won't have the extra complexity which led to this bug. AMD partially avoided this when doing the 64-bit extension (a partial write to the lower 32 bits of a register clears the upper 32 bits), but they kept the legacy behavior for writes to the lower 16 bits, or to either of the 8-bit halves of the lower 16 bits.
Click to expand...
 
To be fair, one is evidently a fringe case that most users don't ever notice, and the other is a "can't run memory at its rated speed" which a big portion of early adopters slammed into on day one.

Fair props to AMD, from what I've read, their later BIOSes have worked wonders, but there's clearly orders of magnitude between the numbers (even as percentages) of people affected by these issues.
 
eddiew said:
To be fair, one is evidently a fringe case that most users don't ever notice, and the other is a "can't run memory at its rated speed" which a big portion of early adopters slammed into on day one.
Click to expand...

Every ryzen system I've built or used has been able to run 2133mhz on memory so I'm not sure where that's come from?
 
amigafan2003 said:
Every ryzen system I've built or used has been able to run 2133mhz on memory so I'm not sure where that's come from?
Click to expand...

TBH I've run @ 2933 from day one. Now @ 3200 (Gigabyte K7)

Built a 1600 sys last week, updated the bios and straight to 3200 no issues (Gigabyte 350 gaming)

Apart from one of the beta bios's I've not had black screen/stability issues either. The beta bios problem was actually a smart fan related issue.
 
eddiew said:
To be fair, one is evidently a fringe case that most users don't ever notice, and the other is a "can't run memory at its rated speed" which a big portion of early adopters slammed into on day one.

Fair props to AMD, from what I've read, their later BIOSes have worked wonders, but there's clearly orders of magnitude between the numbers (even as percentages) of people affected by these issues.
Click to expand...

Ryzen bug was only when it was forced to run code intended for Intel CPU. Hardly an issue, yet it made headlines.
 
amigafan2003 said:
Every ryzen system I've built or used has been able to run 2133mhz on memory so I'm not sure where that's come from?
Click to expand...

Put another way, there's a lot of motherboards were advertising 3200 support on day one, and a lot of people saying they couldn't do it. Maybe that was the board partners' fault rather than AMDs, but either way it looked bad vs Intel where you just plug it in and it works.

On the other hand it does look like this has been largely addressed with BIOS updates, so I'm not demonising AMD here, just saying that a lot of people who wanted those speeds were disappointed for a few months.
 
zornyan said:
if you're on Windows 10 you'll already have the update.

if on win7/8 there's a downloadable update.

it won't effect games, it effects a very select use case that 99% of people won't ever encounter.
Click to expand...
From what i read, it has to be fixed only by when your motherboard manufacturer releases new bios, only a select few cpu revisions can be updated out of bios,
"processors must be either model 78 or 94, and stepping 3, for the intel-microcode fix to work:"
 
Daytrader said:
From what i read, it has to be fixed only by when your motherboard manufacturer releases new bios, only a select few cpu revisions can be updated out of bios,
"processors must be either model 78 or 94, and stepping 3, for the intel-microcode fix to work:"
Click to expand...


you can get the update from here for win 7/8

https://www.reddit.com/r/pcgaming/comments/5vcpb1/psa_when_you_hear_cpu_x_wont_be_supported_in/

win 10 should be handled by the Windows update automatically, or motherboard vendor.

it was fixed by intel back in march, so it's up to Microsoft when the update is pushed out.

still, won't effect 99% of people
 
But that aint even the Hyper Threading problem that this thread is about, what your posting about is completely different, as i posted above, only a few cpu can be fixed by microcode anyway, read here.
https://lists.debian.org/debian-devel/2017/06/msg00308.html

Skylake:

Users of systems with Intel Skylake processors may have two choices:

1. If your processor model (listed in /proc/cpuinfo) is 78 or 94, and
the stepping is 3, install the non-free "intel-microcode" package
with base version 3.20170511.1, and reboot the system. THIS IS
THE RECOMMENDED SOLUTION FOR THESE SYSTEMS, AS IT FIXES OTHER
PROCESSOR ISSUES AS WELL.

Run this command in a command line shell (e.g. xterm) to know the
model numbers and steppings of your processor. All processors must
be either model 78 or 94, and stepping 3, for the intel-microcode fix
to work:

grep -E 'model|stepping' /proc/cpuinfo | sort -u

If you get any lines with a model number that is neither 78 or 94, or
the stepping is not 3, you will have to disable hyper-threading as
described on choice 2, below.

Refer to the section "INSTALLING THE MICROCODE UPDATES FROM NON-FREE"
for instructions on how to install the intel-microcode package.

2. For other processor models, disable hyper-threading in BIOS/UEFI
configuration. Please consult your computer/motherboard's manual for
instructions on how to do this. Contact your system vendor for a
BIOS/UEFI update that fixes "Intel erratum SKW144, SKL150, SKX150,
SKZ7, or the similar one for my Skylake processor".

NOTE: If you did not have the intel-microcode package installed on your
Skylake system before, it is best if you check for (and install) any
BIOS/UEFI updates *first*. Read the wiki page mentioned below.
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom