• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Skylake AVX bug

Page 3 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
MS does for Windows but not very often, usually for critical fixes.

Example of AMD microcode and Windows.
https://support.microsoft.com/en-us/kb/2818604

Pretty interesting that they have been providing µCode updates for those crappy Bobcat APUs, especially when they did not provide one to fix the critical issues which Bulldozers had... I guess it would require some activity from AMD side too in order to MS be able to distribute the updates in the first place 🙄
 
Intel must have extensive test suites, and a huge budget...You do have to wonder, how did this one slip by them?
It isn't like programs like prime95 are rare, so, who dropped the ball on this one?
 
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.
No, it's no how it is with all MPUs. New Intel steppings sometimes include fixes for some errata. It's rare, but it happens.
 
It's just actually impossible to completely verify a modern CPU.
This is not the same as testing different code paths of existing and well known CPU heavy software. But as forcing a specific FFT size to be used for hours is more than running the built in standard tests, this might simply have been missed.
 
More fresh meat.

The very first 386 Steppings had some critical flaws running Protected Mode (32 Bits) Software that made the system to hang. Intel recalled them, tested them, and remarked them with a double sigma symbol, or "16 BIT S/W ONLY". The Windows 3.10 errors for defective 386s are rather amusing.
There are even comments that ocassionally Intel has been extremely tight lipped about errata, like for the 486 era. And please lets not even get started talking about undocumented instructions. The 286/386 LOADALL history is rather interesing.

That blog is really tasty...
 
Last edited:
And thanks to practically producing a copy of the chip, AMD's 386 got the same problems depending on the timeframe of copying it.
 
Seems Intel had a spot of trouble finding this bug because it was already fixed with the microcode they were using to test for it (ver 0x6A). Well, that's the story. :/
 
Asus just launched BIOS 1602 for the Z170-A, which I have. As always, Asus is vague about what's fixed ("stability improvements"), but it appears to include the new CPU microcode. I've run some tests (Cinebench, 7-zip, Sunspider and Geekbench) and at least in those tests there are no performance regressions. Running AVX code is perhaps the most interesting test and I'm not sure if any of the above mentioned use AVX... Does anyone know?
 
CB doesn't, and I really doubt GB does due to its poor x86 support.

Just run something like Linpack before and after. But there is no information that it should affect performance.

You can also use encoders. They tend to use AVX as well.
 
CB doesn't, and I really doubt GB does due to its poor x86 support.

Just run something like Linpack before and after. But there is no information that it should affect performance.

You can also use encoders. They tend to use AVX as well.
Nah, I had some benches from when I upgraded, so just thought I'd re-run some of them to make sure. The microcode is already applied, so can't really make any new comparisons now.

Didn't expect any performance implications, though, and I'm glad these limited tests confirm that.
 
Back
Top