Why the Recent Reported Intel HT Bug is Not in Your Data Center

Yesterday I tweeted out the warning message about the HT bug of Skylake and Kaby Lake processors posted on debian.org.


My tweet got a LOT of retweets. A lot replied with concerns about their systems. I believe most Data Centers will not suffer from this bug as it is present on Skylake and Kaby Lake processors.

What is the Bug?
According to the warning: 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.


Unlikely Present in Your Data Center
The reason why I believe most systems in data centers are not hit by this bug is that it solely applies to E3 Xeons from the Skylake microarchitecture. E3 CPUs are designed to operate in a single socket system, they have no QuickPath Interconnect. Therefore unable to create a symmetric multiprocessing system.

The current E5 (dual-socket) system is based on the Broadwell microarchitecture. The Skylake microarchitecture is expected to appear within the next couple of months. According to the report, they will have the fix included when the product launched. If you are running a NUC in your lab, you might want to check to see whether your system might hit that bug


The link will forward you to a perl script that can help detect if your
system is affected or not. Many thanks to Uwe Kleine-König for
suggesting, and writing this script.


  1. Hi Frank,
    thanks a lot for heads-up. I have Intel NUC 6i3SYH in my home lab where is the processor “6th generation Intel® Core™ i3-6100U processor, 2.3 GHz Dual Core”. It is “Skylake” CPU.

    In Debian mail list (https://lists.debian.org/debian-devel/2017/06/msg00308.html) is written …

    Users of systems with Intel Skylake processors …

    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

    In ESXi, the CPU model can be retrieved by command “esxcli hardware cpu list”
    Luckily enough, I have – Model: 78, Stepping: 3.

    I have the cluster of 4 ESXi nodes and I’m really experiencing some weird CPU issues with these ESXi hosts where hyper-threading is enabled. CPU usage is very often in 100% even there is no VM.

    Disabling hyperthreading is not an optimal solution for me as it would allow me to use just 2vCPUs VMs. I have to do additional research how to upgrade UEFI and install microcode to fix the issue.

    Any additional info you or your readers knows is really appreciated.

  2. Based on info at Frank’s provided link ( https://wiki.debian.org/Microcode ), it seems that only fixed CPU microcode is available as a package for Debian and it has to be reapplied at every boot. Therefore, it is definitely not the solution for ESXi 🙁

    It seems there is new BIOS for Intel NUC
    BIOS Update Instructions for Intel(R) NUC – https://www.intel.com/content/www/us/en/support/boards-and-kits/000005636.html

    … but it most probably does not include microcode.

    So disabling of hyper-threading is probably the only solution at the moment 🙁

    Hope Intel NUC home lab gurus like William Lam, Florian Greh and Andreas Peetz will track this topic and eventually find solution for all of us – Intel NUC home labers 😉

  3. Russell Hamker

    June 27, 2017 at 18:25

    Great Article! Thank you. That helps clear up things.

Comments are closed.

© 2018 frankdenneman.nl

Theme by Anders NorenUp ↑