Skylake AVX bug

Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
Apr 22, 2012
20,395
0
106
#26
Contrary to you, I don't think it will or it won't, because Intel didn't say anything one way or the other ;)


Don't you remember AMD TLB fix?
Yes from how many years ago?

The only 2 bugs I can recall with performance penalty was the FDIV and TLB.
 
Last edited:

The Stilt

Golden Member
Dec 5, 2015
1,709
85
106
#30
Is the AVX issue in question fixed through microcode patch or a ME update?
 

The Stilt

Golden Member
Dec 5, 2015
1,709
85
106
#32
ME doesn't have anything to do with the CPU and resides on the PCH.

Its microcode based.
I thought ME could be used to modify other system parameters, such as PCI config space and such.
 

Dresdenboy

Golden Member
Jul 28, 2003
1,730
0
136
citavia.blog.de
#33
It might be some rare timing/race condition glitch with HT, not affected by the suspected voltages (having droops due to load):

that is the official support answer. They are wrong! The problem is not (!) vcore related. Other voltages like vccsa or vccio also have no affect on this problem. The 768k problem occurs with every common version of prime (27.9, 28.5 and 28.7). Although it will take much longer till a worker fails with 28.7. Sometimes no worker will fail within several hours. If you restart the computer several times a worker might fail within minutes. It's different to common oc problems. At first we thought it was related to the ram training process. But the sub timings are the same when a worker fails or the test runs for hours. The problem will even be there @stock. The issue has been reproduced with CPUs from several forum members
http://mersenneforum.org/showthread.php?t=20714#3
 

EightySix Four

Diamond Member
Jul 17, 2004
5,115
11
91
#36
Interesting suggestion - among the comments - that the bug might not affect i5 processors... Would anyone here with more experience care to chime in?
It has been suggested that it is an issue with Hyperthreading, which means the i5 would not experience it.
 

Dresdenboy

Golden Member
Jul 28, 2003
1,730
0
136
citavia.blog.de
#37
They had microcode yes. FDIV and TLB was so bad only chip replacement would fix it.
As x86 CPUs they of course had µCode ROMs. I meant, if it was patchable back then (via some µCode-RAM), as µCode itself wasn't invented for patching, but to implement complex operations (CISC as it is).

TLB is a structure, which works aside from instruction processing. FDIV was either not patchable back then, or the µCode-slowdown (it was that fast thanks to the lookup tables, which contained some zeroes too many) was not bearable.
 

Nothingness

Golden Member
Jul 3, 2013
1,912
35
106
#38
I guess that nowadays all instructions in Intel CPU are patchable at decode stage: if a pattern is detected it gets replaced or more likely triggers a jump to some microcode, no matter whether it was microcoded or not. It perhaps was not the case back in the FDIV bug days.
 

Dresdenboy

Golden Member
Jul 28, 2003
1,730
0
136
citavia.blog.de
#41
I guess that nowadays all instructions in Intel CPU are patchable at decode stage: if a pattern is detected it gets replaced or more likely triggers a jump to some microcode, no matter whether it was microcoded or not. It perhaps was not the case back in the FDIV bug days.
On RWT someone wrote, that K6 had a simple table, which marked each opcode as fast path or vector decoded. Changing that to vector decoded automatically made it replacable by a µCode routine. The only drawback is a performance loss.
 

videogames101

Diamond Member
Aug 24, 2005
6,768
0
0
#42
The comments on Ars Technica are annoying to me. People seem to be acting like Intel is somehow "slipping" and allowing errors into their hardware at a higher rate than the competition. In addition to the AMD TLB bug everyone knows about, here's a recent example from ARM:

https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00906.html

Any modern CPU will have flaws because the state space is simply too large to completely verify. It's not that Intel, AMD, and ARM are being lazy about verifcation, it's just actually impossible to completely verify a modern CPU. Usually the problems are identified and fixed using ucode or compiler fixes before any end-user notices, and sometimes they aren't.

This is one area where no one is immune, every modern cpu has an errata list :sneaky:
 
Last edited:

cytg111

Diamond Member
Mar 17, 2008
9,617
1,124
136
#43
Just goes to show the old "wait for version 1.1" dogma.
 
Apr 22, 2012
20,395
0
106
#44
Just goes to show the old "wait for version 1.1" dogma.
Why, "version 1.1" will have errors. There isn't going to be any change to Skylake CPUs. This issue is fixed, new will come. Its how it is with all MPUs.
 

cytg111

Diamond Member
Mar 17, 2008
9,617
1,124
136
#45
Why, "version 1.1" will have errors. There isn't going to be any change to Skylake CPUs. This issue is fixed, new will come. Its how it is with all MPUs.
I assume that the biggest and most frequent errors get caught first, thus waiting 3-6 months you will have a better picture of what you're buying. Goes for anything as complex as hardware.
 

Madpacket

Platinum Member
Nov 15, 2005
2,068
0
126
#46
Hmm. Just got a new Skylake w/hyperthreading based Zenbook. Are the McUpdates good enough or will Asus still need to issue BIOS updates?
 
Apr 22, 2012
20,395
0
106
#47
Hmm. Just got a new Skylake w/hyperthreading based Zenbook. Are the McUpdates good enough or will Asus still need to issue BIOS updates?
Depends when Microsoft decides to ship it via Windows update. Sometimes they are a year behind.

You will most likely see BIOS updates first.
 

The Stilt

Golden Member
Dec 5, 2015
1,709
85
106
#48
Depends when Microsoft decides to ship it via Windows update. Sometimes they are a year behind.

You will most likely see BIOS updates first.
Does MS really distribute µCode updates through WU for Intel? I´ve never seen any AMD CPU to use ANY µCode which hasn´t been included in the bios. Regardless if there is any patch present or not. AFAIK Windows cannot even load the patch to AMD CPUs.

I´m referencing to the "MicrocodeUpdateStatus" register key which always has "Newer Patch Not Available" value on AMD CPUs. Regardless if there is any patch loaded or not.
 

Dufus

Senior member
Sep 20, 2010
675
0
101
#49
Yes, microcode can be updated anytime, doesn't have to be done by BIOS.
 

The Stilt

Golden Member
Dec 5, 2015
1,709
85
106
#50
Yes, microcode can be updated anytime, doesn't have to be done by BIOS.
I asked if MS actually distributes the Intel microcodes, since I know as a fact that they don´t distribute any AMD microcodes.
 

Similar threads



ASK THE COMMUNITY

TRENDING THREADS