Arthur T Knackerbracket has found the following story:
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 misbehaviour, 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.
Also at Tom's Hardware and Ars Technica.
Related Stories
AnandTech compared Intel's Skylake-SP chips to AMD's Epyc chips:
We can continue to talk about Intel's excellent mesh topology and AMD strong new Zen architecture, but at the end of the day, the "how" will not matter to infrastructure professionals. Depending on your situation, performance, performance-per-watt, and/or performance-per-dollar are what matters.
The current Intel pricing draws the first line. If performance-per-dollar matters to you, AMD's EPYC pricing is very competitive for a wide range of software applications. With the exception of database software and vectorizable HPC code, AMD's EPYC 7601 ($4200) offers slightly less or slightly better performance than Intel's Xeon 8176 ($8000+). However the real competitor is probably the Xeon 8160, which has 4 (-14%) fewer cores and slightly lower turbo clocks (-100 or -200 MHz). We expect that this CPU will likely offer 15% lower performance, and yet it still costs about $500 more ($4700) than the best EPYC. Of course, everything will depend on the final server system price, but it looks like AMD's new EPYC will put some serious performance-per-dollar pressure on the Intel line.
The Intel chip is indeed able to scale up in 8 sockets systems, but frankly that market is shrinking fast, and dual socket buyers could not care less.
Meanwhile, although we have yet to test it, AMD's single socket offering looks even more attractive. We estimate that a single EPYC 7551P would indeed outperform many of the dual Silver Xeon solutions. Overall the single-socket EPYC gives you about 8 cores more at similar clockspeeds than the 2P Intel, and AMD doesn't require explicit cross socket communication - the server board gets simpler and thus cheaper. For price conscious server buyers, this is an excellent option.
However, if your software is expensive, everything changes. In that case, you care less about the heavy price tags of the Platinum Xeons. For those scenarios, Intel's Skylake-EP Xeons deliver the highest single threaded performance (courtesy of the 3.8 GHz turbo clock), high throughput without much (hardware) tuning, and server managers get the reassurance of Intel's reliable track record. And if you use expensive HPC software, you will probably get the benefits of Intel's beefy AVX 2.0 and/or AVX-512 implementations.
AMD's flagship Epyc CPU has 32 cores, while the largest Skylake-EP Xeon CPU has 28 cores.
Quoted text is from page 23, "Closing Thoughts".
[Ed. note: Article is multiple pages with no single page version in sight.]
Previously: Google Gets its Hands on Skylake-Based Intel Xeons
Intel Announces 4 to 18-Core Skylake-X CPUs
AMD Epyc 7000-Series Launched With Up to 32 Cores
Intel's Skylake and Kaby Lake CPUs Have Nasty Microcode Bug
AVX-512: A "Hidden Gem"?
(Score: 0) by Anonymous Coward on Monday June 26 2017, @10:09PM (3 children)
I have Ubuntu 16.04 and my wife has Window 10. Every 1-2 days one of us has a computer f-up that can only be resolved by hard reboot. What the fuck difference does an occasional Intel-induced reboot make? Fucking computers suck my dick.
(Score: 3, Informative) by jasassin on Monday June 26 2017, @10:16PM (1 child)
Here's a nice perl script some kind soul wrote you can run on your Ubuntu system to see if it is affected:
https://lists.debian.org/debian-devel/2017/06/msg00309.html [debian.org]
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 4, Informative) by kaszz on Monday June 26 2017, @10:31PM
This seems to be the essence of it (and can be decoded manually using dmesg):
if( $vendor eq "GenuineIntel" and $family == 6) {
if ($model == 78 or $model == 94) {
if ($stepping eq "3") {
print "Your CPU is affected, ";
if (hex($microcoderev) >= 0xb9) {
print "but your microcode is new enough\n";
} elsif ($hyperthreading ne "on") {
print "but hyper threading is off, which works around the problem\n";
} else {
print "you should install the latest intel-microcode\n";
}
(Score: 2) by kaszz on Monday June 26 2017, @10:18PM
Machines with Linux could at least be expected to stay online. Seems it may be better to buy an old processor..
(Score: 5, Interesting) by jasassin on Monday June 26 2017, @10:13PM (5 children)
They've only got a microcode fix for two Skylake processors, and all the Kabylake CPU's requires a UEFI update (good luck with that).
This is the kind of shit someone should be sued for. The fix for the rest of the affected processors is to turn of hyperthreading. Unacceptable.
I do have a question, if you install the microcode update is that something that is inserted at boot or is it installed into the CPU itself permanently like a BIOS update?
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 2, Interesting) by Anonymous Coward on Monday June 26 2017, @11:21PM
All the microcode updates involve SRAM changes in-cpu, meaning powering the system off reverts the processors to their fused microcode.
The only exception I have heard of is the OEM motherboard/cpus having an e-fused key which locks the cpu/motherboard together, but you would need to read online for more info on that. (Supposedly the motherboard will attempt to do the same to any non-K series CPU inserted into it, rendering it tied to the motherboard vendor/oem system integrator.
(Score: 1, Touché) by Anonymous Coward on Tuesday June 27 2017, @05:04AM (2 children)
they're not getting sued for this either.
(Score: 2) by jasassin on Tuesday June 27 2017, @06:38AM (1 child)
IIRC they offered replacement CPU's.
Time will tell.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @07:49AM
Correct. A class mate of mine had one of the affected CPUs.
They didn't offer replacements for the F0 0F C7 C8 bug a few years later, though.
(Score: 1, Interesting) by Anonymous Coward on Tuesday June 27 2017, @07:37AM
Microcode updates are normally stored in flash on the motherboard, alongside the BIOS. The BIOS provides new microcode to the CPU at start-up.
Linux is capable of doing a microcode update. This would happen as the init scripts run. Doing a microcode update while running a "real" operating system isn't a great idea; ideally the boot loader (typically grub) would handle it. Consider the "fun" that could happen with a microcode update that affects how a CPU interacts with other CPUs on a motherboard that has more than one CPU active.
(Score: 4, Insightful) by kaszz on Monday June 26 2017, @10:22PM (5 children)
1994 Pentium FDIV bug [wikipedia.org]
1997 Pentium F00F bug [wikipedia.org]
2017 Intel AMT, "strncmp()"
Seems they keep up the tradition? ;)
(Score: 5, Insightful) by takyon on Monday June 26 2017, @11:03PM
Couldn't have come at a better time for AMD. Right in the middle of its struggle to regain market share. And AMD is trying to compete with Xeons as well.
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 4, Interesting) by bob_super on Monday June 26 2017, @11:55PM (3 children)
> 1997 Pentium F00F bug
Stay the [bleep] away from F00F [sciencemag.org]
NSFW warning: Not sex, but it's really hard not to laugh.
(Score: 2) by LoRdTAW on Tuesday June 27 2017, @12:13AM
Thanks for that link. Not a chemistry person but I found it a very Interesting read.
(Score: 2) by Spamalope on Tuesday June 27 2017, @02:22PM (1 child)
Haha! His blog is fantastic.
One of the commenters was annoyed that every time they looked for chemical suppliers a few China based companies spammed the entire supple sites claiming they were suppliers for everything added 'weed out those guys' to the work for every search.
Someone pointed out he could just order ten pounds and solve his problem. It'd also locate the spammers, as we could find the (former) location of their lab by looking for the crater on google earth. No chance of synthesizing anywhere near that amount without something... energetic happening.
(Score: 0) by Anonymous Coward on Wednesday June 28 2017, @09:08AM
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @06:44AM
(Score: 2) by shortscreen on Tuesday June 27 2017, @09:08AM (2 children)
I guess modern compilers don't use AH,BH,CH,DH much huh? When Intel was testing out their fresh chips they must have forgot to run some vintage hand coded assembly.
(Score: 1, Informative) by Anonymous Coward on Tuesday June 27 2017, @09:40AM (1 child)
From the description, emphasis by me:
I cannot imagine any 64 bit code that doesn't use RAX, RBX, RCX or RDX, nor any 32 bit code that doesn't use EAX, EBX, ECX or EDX.
(Score: 2) by Dr Spin on Tuesday June 27 2017, @02:24PM
The way I understood this, the bug is tripped when you use the 8 bit reg in one thread and the extended reg
in another thread.
Have I read it wrong?
(I read the OpenBSD description, but on a phone, without my glasses).
I suggest that this is more evidence that a monoculture is high risk. I can't wait to see Arm servers able
to compete on performance in the "8 to 64 thread" market. It would be nice to see greater diversity in
memory interfaces too.
Warning: Opening your mouth may invalidate your brain!
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @12:56PM
for "kaby lake(gen7)" (and "skylake"(gen6)) there's a nice document from intel listing all "errata".
also the affected CPUs are listed by name (and stepping).
other then that, thanks for scaring people into sending AMD their moneys : D