Skylake / Kaby Lake Hyper-threading bug

According to some debian developers, all Skylake and Kaby Lake (Desktop and mobile) processors are affected by a bug related to Intel's HT technology. It can cause "unpredictable system behavior", which means everything from simple calculation errors to system erros and even data loss. It does only occur on certain instructions and cases and has to be fixed by a microcode (BIOS) update.

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

As such errors are very common, it is still a drawback for all notebook users, because some machines might never receive an update for this bug.

* First reported by @ajc9988 @TANWare in the Intel Core-X thread !

* There is a way to update the CPU microcode to fix this issue without the need of a new BIOS version. Check post #51 for details !

 

Update: @Dufus has instructions for using the "VMware CPU Microcode Update Driver" that can be used to apply the latest Microcode updates for your CPU until a new BIOS with the Intel HT microcode patches is released for your computer:

[How to] Update microcode from Windows
---------------------------------------------
This might explain a lot of the "unexplainable" inconsistent behavior reported here from users... wow.

In short, disable hyperthreading in the BIOS until you can get a BIOS / microcode update to fix the errata.

@Phoenix @Papusan @Diversion @Shehary @HTWingNut @iunlock @Mr. Fox @mason2smart @Prema @TBoneSan @unclewebb @Rage Set @dspboys @ThePerfectStorm @DukeCLR @Coolane @Johnksss@iBUYPOWER @saturnotaku @iDave @Falkentyne @Coruscator @HardCoreGamer4Life @Arestavo @BanditBuzz @Atma

@every-one-with-a-Skylake-Kabylake-CPU...sorry to those I skipped, it's a long list

Intel's Skylake and Kaby Lake CPUs have nasty microcode bug
Debian devs noticed errata to deep docs and now the fit's hitting the shan
https://www.theregister.co.uk/2017/06/25/intel_skylake_kaby_lake_microcode_bug/

"During April and May, Intel started updating processor documentation with a new errata note, and over the weekend we learned why: Skylake and Kaby Lake silicon has a microcode bug."

"The errata is described in detail on the Debian mailing list, and affects Skylake and Kaby Lake Intel Core processors (in desktop, high-end desktop, embedded and mobile platforms), Xeon v5 and v6 server processors, and some Pentium models."

"The Debian advisory says affected users need to disable hyper-threading “immediately” in their BIOS or UEFI settings, because the processors can “dangerously misbehave when hyper-threading is enabled.”

Symptoms can include “application and system misbehavior, data corruption, and data loss”.

Henrique de Moraes Holschuh, who authored the Debian post, notes that all operating systems, not only Linux, are subject to the bug.

Intel's errata note (for example in this document), describes the issue like this:

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 (eg 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.

The issue went rose above obscurity when Mark Shinwell, a developer working on the OCamlL toolchain, contacted the Debian team to explain that the OCaml compiler triggered an Intel microcode issue.

Fixes
Debian's post notes that Intel has documented the bug and its microcode fixes for Core 6th generation, Core 7th generation, Xeon v5 and v6, and Core 6th generation X series.

For Debian users:

• Kaby Lake – contact system vendors for BIOS/UEFI updates, and in the meantime disable hyper-threading;
• Skylake – Depending on model, an intel-hyperthreading package is available; otherwise disable hyper-threading and wait for a BIOS/UEFI fix.

Other users will need platform-specific fixes, or for BIOS/UEFI upgrades to land from their system vendors."

 

Serious Intel Skylake and Kaby Lake microcode bug unearthed
http://hexus.net/tech/news/cpu/107293-serious-intel-skylake-kaby-lake-microcode-bug-unearthed/

"Over the weekend an Intel processor microcode bug was highlighted with a warning advisory via the Debian.org mailing lists. Henrique de Moraes Holschuh warned that systems equipped with Intel Skylake and Kaby Lake processors could "in some situations, dangerously misbehave when hyper-threading is enabled." The errant behaviour could include "application and system misbehavior, data corruption, and data loss," all of which are serious for practical computer use."

Lots more news outlets have checked-in articles on this...

 

This was covered under the Intel thread at first too. by @ajc9988 .

 

@ALLurGroceries please sticky this thread, it's an important problem with a temporary fix (disable hyperthreading in UEFI / BIOS) that all Skylake / Kabylake owners need to know about.

Agreed, This thread for now needs a sticky. (added by @TANWare ?)

Edit: How can this sticky be promoted to each vendor's forum that uses Skylake / Kabylake CPU's? In other words, what is the best way to get notice to everyone that reads NBR that is affected?

 

I honeslty didn't saw that and a quick forum search gave me no results on that topic, I will link to that in the first post.

 

Unless you don't backup your important Data; disabling Hyper-threading is an Overreaction.

You got about the same chance of getting hit by lightning as causing a critical error with this bug. Light erratic system behavior is ok to live with until fix

 

I was using using Skylake for overs a year and never had any problem, so i won't turn off hyper threading or wait bios update.

 

We just have to hope that notebook manufacturers release the fix, rather than dismissing it as "light erratic system behavior." I think the large OEMs (HP, Dell, Lenovo) will come through, but I'm less certain about Asus, MSI, Clevo, since they don't have nearly the market share.

 

I hope Intel does not provide the CPU for the mission to mars or some robotic surgery machine.

John.

 

Like any other bug, it can cause a crash and thereby data loss. Still not a good thing but as mentioned so long as you keep your data backed up, not too big a deal right now. Of course though Intel people will play this down too, but this is the game we all play.

 

This was already debunked over on OCN. NO kaby lake processors were affected to begin with.

http://www.overclock.net/t/1633031/...ocessors-broken-hyper-threading#post_26184505

This "bug" was fixed over a year ago.

 

I would want to see a release from Intel. But if confirmed already fixed we can unsticky it, not till then though.

Edit; if this again is a truly fixed issue Intel needs to get on it as quite a few other media sites are jumping on the story as well.

 

Intel just recently documented that in their CPU spec sheets:

https://www3.intel.com/content/dam/...s/desktop-6th-gen-core-family-spec-update.pdf

Errata - SKL150 - April 2017

Would be interesting to know, if and when they provided OEM's and system vendors with the update.

 

I hear you, but it now makes me think. I had information get corrupted. I attributed it to a memory overclock, even though tests came back with zero errors and stable. It makes me wonder if this was the case instead. It was few and far between, and only in cases with certain programs I used (certain operations). But, the rest of the data and uses I do have been fine. It just makes me wonder...

Sent from my SM-G900P using Tapatalk

Edit: seems I need to update my bios again, then. I'm using one from either February or March, skylake 6700K. I'll need to write down the bios settings and hope my memory clocks remain the same (bios changes on this board have made overclocked memory settings vary by bios)...

 

@Falkentyne DrFPS is a clueless person and/or trying to troll their thread. Read the responses. Did anyone else actually read his post and responses?

Spoiler: falkentynes link, post and responses

DrFPS - "Fake.
All the reviews and not one time has one person claimed this processor hangs up.

If it did it would be able to make it hang over and over. This is not the case.

Google search, all points back to the same source. Reason for that is it's fake."

CynicalUnicorn - "Yes. It sure is fake. That's why Intel found and isolated the bug and promptly patched it."

Particle - "I sure am glad some random person with Google is here to set the record straight. Operating system developers are always trying to pull one over on us with their incompetent fake assertions."

The discovery of the bug was over a year ago in 2016, the fix wasn't logged until April of 2017, by Intel.

It's just recently enough that most people won't have updated their BIOS to fix the problem.

It can take months for a vendor to build a BIOS with that errata fix, test it, distribute it, and for people to finally download and install it.

It's way too early to say it's fixed and shut the thread down

Here is the entire warning posting, read the entire warning. It says the bug goes back to 2016, but the fix wasn't included by Intel until April.

Spoiler: This warning advisory is relevant for users of systems with the Intel processors code-named "Skylake" and "Kaby Lake"

[WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
This warning advisory is relevant for users of systems with the Intel
processors code-named "Skylake" and "Kaby Lake". These are: the 6th and
7th generation Intel Core processors (desktop, embedded, mobile and
HEDT), their related server processors (such as Xeon v5 and Xeon v6), as
well as select Intel Pentium processor models.

TL;DR: unfixed Skylake and Kaby Lake processors could, in some
situations, dangerously misbehave when hyper-threading is enabled.
Disable hyper-threading immediately in BIOS/UEFI to work around the
problem. Read this advisory for instructions about an Intel-provided
fix.

SO, WHAT IS THIS ALL ABOUT?
---------------------------
This advisory is about a processor/microcode defect recently identified
on Intel Skylake and Intel Kaby Lake processors with hyper-threading
enabled. This defect can, when triggered, cause unpredictable system
behavior: it could cause spurious errors, such as application and system
misbehavior, data corruption, and data loss.

It was brought to the attention of the Debian project that this defect
is known to directly affect some Debian stable users (refer to the end
of this advisory for details), thus this advisory.

Please note that the defect can potentially affect any operating system
(it is not restricted to Debian, and it is not restricted to Linux-based
systems). It can be either avoided (by disabling hyper-threading), or
fixed (by updating the processor microcode).

Due to the difficult detection of potentially affected software, and the
unpredictable nature of the defect, all users of the affected Intel
processors are strongly urged to take action as recommended by this
advisory.

DO I HAVE AN INTEL SKYLAKE OR KABY LAKE PROCESSOR WITH HYPER-THREADING?
-----------------------------------------------------------------------
The earliest of these Intel processor models were launched in September
2015. If your processor is older than that, it will not be an Skylake
or Kaby Lake processor and you can just ignore this advisory.

If you don't know the model name of your processor(s), the command below
will tell you their model names. Run it in a command line shell (e.g.
xterm):

grep name /proc/cpuinfo | sort -u

Once you know your processor model name, you can check the two lists
below:

* List of Intel processors code-named "Skylake":
http://ark.intel.com/products/codename/37572/Skylake

* List of Intel processors code-named "Kaby Lake":
http://ark.intel.com/products/codename/82879/Kaby-Lake

Some of the processors in these two lists are not affected because they
lack hyper-threading support. Run the command below in a command line
shell (e.g. xterm), and it will output a message if hyper-threading is
supported/enabled:

grep -q '^flags.*[[:space:]]ht[[:space:]]' /proc/cpuinfo && \
echo "Hyper-threading is supported"

Alternatively, use the processor lists above to go to that processor's
information page, and the information on hyper-threading will be there.

If your processor does not support hyper-threading, you can ignore this
advisory.

WHAT SHOULD I DO IF I DO HAVE SUCH PROCESSORS?
----------------------------------------------
Kaby Lake:

Users of systems with Intel Kaby Lake processors should immediately
*disable* hyper-threading in the BIOS/UEFI configuration. Please
consult your computer/motherboard's manual for instructions, or maybe
contact your system vendor's support line.

The Kaby Lake microcode updates that fix this issue are currently only
available to system vendors, so you will need a BIOS/UEFI update to get
it. Contact your system vendor: if you are lucky, such a BIOS/UEFI
update might already be available, or undergoing beta testing.

You want your system vendor to provide a BIOS/UEFI update that fixes
"Intel processor errata KBL095, KBW095 or the similar one for my Kaby
Lake processor".

We strongly recommend that you should not re-enable hyper-threading
until you install a BIOS/UEFI update with this fix.

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.

INSTALLING THE MICROCODE UPDATES FROM NON-FREE:
-----------------------------------------------
Instructions are available at:

https://wiki.debian.org/Microcode

Updated intel-microcode packages are already available in non-free for:
unstable, testing, Debian 9 "stretch" (stable), and Debian 8 *backports*
(jessie-backports).

THE MICROCODE PACKAGES FROM THE RECENT STABLE RELEASE (June 17th, 2017)
ALREADY HAVE THE SKYLAKE FIX, BUT YOU MAY HAVE TO INSTALL THEM.

Updated intel-microcode packages in non-free for Debian 8 "jessie"
(oldstable) are waiting for approval and will likely be released in the
next non-free oldstable point release. They are the same as the
packages in non-free jessie-backports, with a change to the version
number.

The wiki page above has instructions on how to enable "contrib" and
"non-free", so as to be possible to install the intel-microcode package.

Users of "jessie" (oldstable) might want to enable jessie-backports to
get *this* intel-microcode update faster. This is also explained in the
wiki page above.

MORE DETAILS ABOUT THE PROCESSOR DEFECT:
----------------------------------------
On 2017-05-29, Mark Shinwell, a core OCaml toolchain developer,
contacted the Debian developer responsible for the intel-microcode
package with key information about a Intel processor issue that could be
easily triggered by the OCaml compiler.

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 a microcode defect with unknown hit-ratio in the
intel-microcode package changelog. He matched it to the issues the
OCaml community were observing, verified that the microcode fix indeed
solved the OCaml issue, and contacted the Debian maintainer about it.

Apparently, Intel had indeed found the issue, *documented it* (see
below) and *fixed it*. There was no direct feedback to the OCaml
people, so they only found about it later. (not a year later, weeks later)

The defect is described by the SKZ7/SKW144/SKL150/SKX150/KBL095/KBW095
Intel processor errata. As described in official public Intel
documentation (processor specification updates):

Errata: SKZ7/SKW144/SKL150/SKX150/SKZ7/KBL095/KBW095
Short Loops Which Use AH/BH/CH/DH Registers May Cause
Unpredictable System Behavior.

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.

Implication: Due to this erratum, the system may experience
unpredictable system behavior.

We do not have enough information at this time to know how much software
out there will trigger this specific defect.

One important point is that the code pattern that triggered the issue in
OCaml was present on gcc-generated code. There were extra constraints
being placed on gcc by OCaml, which would explain why gcc apparently
rarely generates this pattern.

The reported effects of the processor defect were: compiler and
application crashes, incorrect program behavior, including incorrect
program output.

What we know about the microcode updates issued by Intel related to
these specific errata:

Fixes for processors with signatures[1] 0x406E3 and 0x506E3 are
available in the Intel public Linux microcode release 20170511. This
will fix only Skylake processors with model 78 stepping 3, and model 94
stepping 3. The fixed microcode for these two processor models reports
revision 0xb9/0xba, or higher.

Apparently, these errata were fixed by microcode updates issued in early
April/2017. Based on this date range, microcode revision 0x5d/0x5e (and
higher) for Kaby Lake processors with signatures 0x806e9 and 0x906e9
*might* fix the issue. We do not have confirmation about which
microcode revision fixes Kaby Lake at this time.

Related processor signatures and microcode revisions:
Skylake : 0x406e3, 0x506e3 (fixed in revision 0xb9/0xba and later,
public fix in linux microcode 20170511)
Skylake : 0x50654 (no information, erratum listed)
Kaby Lake : 0x806e9, 0x906e9 (defect still exists in revision 0x48,
fix available as a BIOS/UEFI update)


References:
https://caml.inria.fr/mantis/view.php?id=7452
http://metadata.ftp-master.debian.org/changelogs/non-free/i/intel-microcode/unstable_changelog
https://www.intel.com/content/www/us/en/processors/core/desktop-6th-gen-core-family-spec-update.html
https://www.intel.com/content/www/us/en/processors/core/7th-gen-core-family-spec-update.html
https://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v6-spec-update.html
https://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v5-spec-update.html
https://www.intel.com/content/www/us/en/products/processors/core/6th-gen-x-series-spec-update.html

[1] iucode_tool -S will output your processor signature. This tool is
available in the *contrib* repository, package "iucode-tool".

--
Henrique Holschuh

We need to keep getting the word out so people know to look for updated BIOS's and firmware for their laptops.

You can follow the mailing list conversation where that warning was posted here:

Date Index:
https://lists.debian.org/debian-devel/2017/06/maillist.html#00322

Thread Index:
https://lists.debian.org/debian-devel/2017/06/threads.html#00322

The discussion may jump subject names, so it's best watch both indexes...

 

I saw that too, again awaiting to hear an Intel response to this.

 

Intel just responded:

[Updated] Critical Flaw In Intel Skylake And Kaby Lake HyperThreading Discovered Requiring BIOS Microcode Fix
https://hothardware.com/news/critic...ading-discovered-requiring-bios-microcode-fix

"Update: 6/26/2017, 8:59PM EST - Our contacts at Intel have responded to our requests for further detail on this issue with the following statement":

"We have already identified this issue and addressed it with a fix that started rolling out in April 2017. As always, we recommend checking to make sure your BIOS is up to date, but the chance of encountering this issue is low, as it requires a complex number of concurrent micro-architectural conditions to reproduce."

The Debian team's suggest disabling hyperthreading as a precaution until you can get a BIOS with the updated errata integrated, and Intel doesn't say anything one way or the other in their short quote...but the article author jumped forward with:

"Regardless, it appears as though Intel does not recommend disabling HyperThreading in light of this issue, which of course is counter to what the Debian Linux user group has recommended from the outset. "

I'd just re-emphasize that Intel simply didn't say anything one way or the other, so I wouldn't jump to the conclusion that they did.

Further important details from the article:

"Kaby Lake’s status is less certain at this point and may still be vulnerable. Intel’s microcode updates from April 2017 with revisions 0x5d/0x5e and higher may fix the flaw for Kaby Lake processors that have signatures 0x806e9 and 0x906e9, but the safest course of action is to disable HyperThreading for now. The status of Intel's new Skylake-X and Kaby Lake-X series CPUs is unknown.

This situation serves as a cautionary reminder to not only keep up with operating system updates, but to keep tabs on driver and BIOS/UEFI updates as well. For more information, consult the Debian release, available here."

Again, I'd track the Debian mailing list posts for more info, and if I can find a spot where Intel is posting updates about this I'll post that too.

 

I expect Intel has tested and tested this in all types of settings. Disable or not... All depends how important your workflow is. The average consumer wouldn't jump into problems. And will all ODM's (laptops) fixing this flaw for all their models? I'm not sure about that. And if they fix it. How long will it take?

 

Supposedly the fix is in the April errata, but looking at the debian include file text it's not a for sure fix yet, it's still under the unstable build as well:

* Likely fix nightmare-level Skylake erratum SKL150. Fortunately,
either this erratum is very-low-hitting, or gcc/clang/icc/msvc
won't usually issue the affected opcode pattern and it ends up
being rare.
SKL150 - Short loops using both the AH/BH/CH/DH registers and
the corresponding wide register *may* result in unpredictable
system behavior. Requires both logical processors of the same
core (i.e. sibling hyperthreads) to be active to trigger, as
well as a "complex set of micro-architectural conditions"

http://metadata.ftp-master.debian.org/changelogs/non-free/i/intel-microcode/unstable_changelog

Likely isn't for sure, but then again, I thought the debian build had been tested with the fix. But, I think it's still undergoing testing. I'll watch the mailing list to see if any updates show up.

 

@XMG has the XMG U727 2017 BIOS been updated with this microcode update yet? My Laptop has the 1.05.05 BIOS version with KBC/EC Firmware Revision 1.05.02 and ME FW 11.6.10.1196 it came with. Does this BIOS already have the fixed microcode or is there an updated BIOS available yet and where (can't find anything newer than my already installed BIOS in the mysn downloads section)? It doesn't seem I can disable Hyperthreading in my BIOS either (BIOS options such as hyperthreading, XD bit, Virtualization, etc. should really be available in any release).

Update: My CPU Microcode Update Revision appears to be 48 according to HWInfo.

It might be a good idea if other vendors chimed in on the status of their Skylake and Kabylake based systems regarding this issue as well.

 

These are both excellent questions to ask each and every vendor / maker, to get the status of the fix in the BIOS release cycle, and to get the Hyperthreading enable/disable option back into the BIOS.

 

If you can recreate the symptoms by running that software again, and then disable hyperthreading, it would be interesting to know if it was the cause.

The instability isn't just "crashing", it can be any corruption caused at the time of an event, sometimes it will not have any effect, sometimes it will.

I've often debugged anomalous behavior that is so rare I need thousands of servers to get a "clue" as to the cause, then when I have a good theory and I can recreate the problem at will, the underlying hardware failure can be isolated.

I've found improperly installed memory this way many times. And, failing battery backup on RAID cards. Failing ID chips in motherboards (Sun). And, finding and isolating varying levels of firmware compliance for failing OOB support.

Memory seems to run everything fine except different OS features report varying data back "differently" - size or value expected isn't exactly correct, but passes vetting of the database sanity checks.

Or, an application that runs various simulations comes up with "odd" answers as compared to running on previous systems - validating running on new hardware and OS.

Firmware variances across 10k machines can have similar effects to what is seen with errata fixes missing across some machines, but not others.

When you are running a large number of machines 24 / 7, 1 in a million situations can come up hourly

It's a matter of experience and perception. Better safe than sorry, better to check to see if hyperthreading off solves strange anomalous behavior - it can be a quick test to take it off the checklist - and mind.

 

The Kabylake CPU's are supposed to be affected, but the only info we have on a fix is for the 6th Gen CPU's, I only found SKL150 for Skylake, search this doc for SKL150 for more info:
https://www3.intel.com/content/dam/...s/desktop-6th-gen-core-family-spec-update.pdf

The debian, Intel, and other notes so far say there is no fix for the 7th Gen. Kabylake, but it is affected.

I would imagine that the Kabylake X CPU's are a clone of the existing Kabylake CPU's, so they would also have the same issue.

IDK if the Skylake-X CPU's are counted in the same errata for the Skylake CPU's, but since they are so new I would assume the frequent BIOS updates should get them covered quickly after release.

All good questions

 

Here is someone that was able to come up with a repeatable failure test, that didn't fail when Hyperthreading was disabled:

https://hardforum.com/threads/skyla...oken-hyper-threading.1938149/#post-1043078134

"I found a set of conditions that each time I perform it, my machine will lock up.

I just tried without HT enabled and it works fine.
So looks like this bug affects me with my 6700K.

The bizarre condition is:
Win7-64
Running torrent client in a sandbox.
Sandbox and torrent client have limited system access via Comodo Firewall HIPS (not sure if this is relevant but it may help trigger it).

If I am downloading a torrent and try to play a card game (windows built in games) to pass the time, my machine will hard lock. Every time.

If I open the card game first or stop the torrent or let the torrent finish it works without issue.

I thought it might be related to locked down security issues but as its something basic I can cope with I didnt pursue a solution.

I tested opening a card game with a torrent downloading with HT disabled and it works fine.

So that explains that."

Even better, he found that the latest BIOS for his motherboard fixed the problem

"Replying to my post to confirm that updating to the latest motherboard bios has fixed the problem.
No crash with HT enabled now.
My motherboard is the Asus Maximus VIII Hero.
Previous bios version 2001 29/08/16
New bios 3401 07/04/17

If the problem was caused by this bug, the CPU fix is in the latest bios."
https://hardforum.com/threads/skyla...yper-threading.1938149/page-2#post-1043079608

 

I am leaving this post as a placeholder, so that I can make a more comprehensive reply and deal with all the questions in one place. To do this, I am checking the situation with BIOS versions and associated microcode for both the Skylake and KB CPU systems in order to cover all bases.

But for now I will say two things:

1/ if people are reporting a problem with software running with HT enabled and that disabling it means that the software runs better or without problems, this can't be used to conclude that the root cause with HT on is the exact problem that we're discussing on this thread. It could be due to this problem, but the link needs to be proved before we can argue that someone has definitely replicated the exact same issue.

2/ it's extremely rare and only a handful of people have been able to replicate it (literally a handful). It is a bug, Intel have confirmed this via other media, and there is a fix.

Will update once 100% of the information is gathered in order to try and clarify the status for everything.

UPDATE http://forum.notebookreview.com/thr...er-threading-bug.806317/page-10#post-10558834

 

And, I think it just goes to show that disabling HT is still, after so many years, a good step to take when debugging odd situations like the one Nenu from HardForum.com posted.

As he posted, in Nenu's specific case, doing a BIOS update that likely includes the Intel Skylake HT microcode patch fixed his repeatable problem, the same as turning off HT in the BIOS - now he can run with HT Enabled.

Maybe it's just too good to be true to find a person that can demonstrate the problem (to himself) and that he found the solution in the BIOS update. He was running a year old BIOS, maybe there were other BIOS fixes during that year that fixed his specific issue?

Maybe if you have an odd problem on your Skylake / Kabylake system that so far debugging hasn't solved, you could try disabling HT in the BIOS and see if the problem goes away.

Or, find and update your BIOS with the latest Errata patches, and not worry about it any more

 

As far as I know, using VMware's driver to perform the microcode updates when the system boots is a good idea and should workaround this bug. The final step would be having the microcode update integrated into the BIOS update to fix the issue permanently and for good.

See:
http://forum.notebookreview.com/threads/how-to-update-microcode-from-windows.787152/

My two cents.

Regards,
Jorge Manuel Silva

 

Also, another good rule of thumb on virtual machines. You need to allow the host machine to be 2x-3x the need of the software and OS you're using virtually, this is on CPU speed and RAM. The VMWare driver doing updates it needs is also wise. Full voltage Core i7 at higher clock speeds is a good CPU for Virtual machines. I also recommend 12-16 GB of RAM or more, fewer issues that way.

 

Sorry man, you mis-read the point of the thread.

Thanks for the VM tips though, I'm sure someone will find them useful in another thread focused on VM's.

This thread is about getting Skylake / Kabylake (when available) CPU microcode updates into Windows, not into a virtual machine.

Only the last post, just before your's, mentioned a method using a tool from VMware to use in the host machine to update CPU microcode.

Useful when VMware discovers a bug in a CPU and Intel provides a fix - the tool can apply the fix immediately instead of waiting for a BIOS update from the motherboard maker.

Read from the 1st post, and find out about the errata available to fix a CPU Hyperthreading bug

 

@hmscott: I updated the microcode via ubuntu. Download latest deb file for 17.04, unpacked it and opened up terminal and typed make and the patch is installed.

 

Yeah, Linux is (should be) a pretty easy patch fix received through normal updates.

Windows has the VMware tool.

And, I know of ways to do this through patching the BIOS, but it's not critical enough of a problem unless you are system down from it right now to direct someone to play with their BIOS and maybe brick it from flashing a custom BIOS...

It seems there is enough awareness for vendors to make it a quick path to a patch / BIOS update.

Thanks for the update, glad you got it fixed + I assume you got the roll up of all the microcode patches since the last Linux include update; and all of this should be rolling out to everyone "invisibly" in the next Linux update(s).

 

No, I updated it manually by downloading the deb file containing the microcode errata fix. If I subscribe to 17.04 repository, i will get constant unstable microcodes, For users on ubuntu 16, I recommend downloading the microcode from launchpad.net's 17.04 repo. By default Ubuntu 16 uses older microcode update dated 2015.

 

That sucks, so the normal updates don't roll up CPU microcode updates?

Those should roll out to everyone on a regular (monthly) basis along with security patches.

Sheeesh, what are they thinking?

Maybe you can file a suggestion to do just that, monthly updates with CPU microcode rollups along with security patches.

 

Looking forward to MSI releasing a BIOS fix for this issue for my motherboard - fingers crossed! In the meantime I won't be disabling hyperthreading as I haven't had any unexplained crashes so far, but would like this issue to be patched by vendors soon. As soon as MSI release a fix for my motherboard I'll post back here.

 

Normal users won't need it and there's a flip side to it, sometimes your working CPU will be borked if in case the user shuts down the machine during update. Its just a matter of updating CPU FW and no need for BIOS update.

Try LiveCD of ubuntu or you can wait for the update, I think ASRock already shipped the BIOS.

 

I think you read "BIOS update" into my text, but I didn't have those words in there, I said microcode update through an OS update, nothing to do with flashing the BIOS.

That's the benefit of doing the microcode update via the OS update, no risk of borking from the user doing a shutdown during an update.

 

I'm sorry, it should be after @Robbo99999 quote.

 

I'm not going to disable hyper-threading. No reason to at this point because nothing behaves like it is broken, so I'm not going to burn any calories fretting over it. It would be nice to have a fix forthcoming in a BIOS update, but I'm not finding any problems to complain about. I'd be more upset if a microcode update did something to reduce my performance or impaired my overclocking. That would suck more than ignoring a bug that doesn't seem to be affecting me.

 

I found out the microcode didn't install, so uninstall current intel microcode and download the deb file and patched it, now its patched up. @Mr. Fox I will do some gaming and report back. @hmscott I''ll post the picture in a moment.
EDIT: I used VMWare CPU uCode updater and finally result is here.
Revision is changed from 9B to BA.

 

Test with the CPU running at 5.2GHz if you would, please. That's the clock speed I run mine at most of the time.

If you find it improves performance, I have a Linux Mint installation on a spare M.2 that I can swap into my chassis and use to install the microcode. I only need to take out one screw to make that change... about 30 seconds worth of work, so let me know.

Thanks!

 

@hmscott @Mr. Fox @Papusan: Before uCode update:

After uCode Update:

I'm using BGA 6700HQ.

 

Sorry to disappoint you @Mr. Fox mine is BGA turdbook AW.

 

No worries. What I read here https://wiki.debian.org/Microcode indicates that Linux applies the microcode at every boot and it's not really flashed to the system firmware. Not sure if I am reading that correctly or not, but it that is the case and it is a volatile method and it would not be a useful solution to temporarily swap in my Linux drive.

 

Try this if you want in windows. You can install and uninstall the uCode at a click of a button. http://forum.notebookreview.com/threads/how-to-update-microcode-from-windows.787152/
In linux, you need to uninstall existing intel microcode and download the deb file [ direct download] or [ manual search and download ] and install it using gdebi.
EDIT: Use Synaptic package Manager to uninstall existing uCode.

 

@Mr. Fox: For me, 6700HQ can consistently keep up its turbo speed for longer periods on heavy CPU loads. Some minor improvements, for me an increase in 2MHz in CPU clocks. Somewhat CPU has lesser stutters after uCode update.
Here's before & after uCode update on Firestrike:
Before: http://www.3dmark.com/fs/12629662
After: http://www.3dmark.com/3dm/20763199?
One more thing, I observed a loss of 20 points in Cinebench r15 from 683 to 663.

 

Thanks

Thank x2

 

Just got confirmation from @Prema that his latest BIOS mods already have the latest microcode and those machines don't need to be fixed. This includes the HIDevolution EVOC 16L-G-1080 BIOS mod and all of his Clevo P7/P8 DM2/3 with v2.X and newer BIOS versions.

 

+Rep for testing.
20 points down in Cinbench R15 is much more noticeable than the minor changes in Firestrike bench(physics score). Could you please run more Cpu tests. Both before and after fix. Wprime 32M - 1024M, Cinbench R11.5 - R15. Especially the longer Wprime 1024M bench is of interesting as you say the processor consistently can keep up it's Turbo speed in prolonged periods. As well 3DM11. Thanks

 

It will effect all kind of OS [No matter what!] becuase it is a microcode CPU bug so.... you may have a chance to fix it by your self through my guide

here is my guide

http://forum.notebookreview.com/thr...s-broken-ht-on-laptops-pc-fix-is-here.806451/