[QUOTE=tha;421245]No, not yet. I have a couple of other tests that I want to run first. About 12 more hours before the current test completes. I lost some more time trying to compile mprime than i thought beforehand.[/QUOTE]

Always trust yourself more than others.

Always trust that others are smarter than yourself.

You will find that laughter comes to you naturally when you realize that most are smarter than you are.... :smile:

[QUOTE=tha;421243]That was the one I tried first, and actually I am still amazed it doesn't work. That package is installed.[/QUOTE]

[code]I have problems compiling with my unofficial and unsupported multilib setup.
If you are using multilib packages from somewhere and also have some 32bit packages installed, then you might run into problems with the build process trying to link 32bit libraries instead of 64bit libraries. If this occurs, it can probably be solved by placing the following line:
LDFLAGS="-L/usr/lib${LIBDIRSUFFIX}" \
after the lines for CFLAGS and CXXFLAGS passed to the configure script. In other words, make it look something like this:
CFLAGS="$SLKCFLAGS" \
CXXFLAGS="$SLKCFLAGS" \
LDFLAGS="-L/usr/lib${LIBDIRSUFFIX}" \
./configure \
Beyond that, you are on your own. This is an unsupported setup.[/code]

for the last one at least suggested on linuxquestions.

[QUOTE=chalsall;421247]Always trust yourself more than others.

Always trust that others are smarter than yourself.

You will find that laughter comes to you naturally when you realize that most are smarter than you are.... :smile:[/QUOTE]

And remember that half the people you meet have below average intelligence. :smile:

Find the results of the second run below added to the previous results. The asterisks and equal signs have been added by hand and indicate whether the results match the database and the previous result.

[CODE]
[Sat Jan 2 18:39:23 2016]
M14942437 is not prime. Res64: 683A0DFFC5827CD8. We8: E57106A7,7379210,00000000
M14942267 is not prime. Res64: C35562BC4F3511F3. We8: D8A74C7B,2423514,00000000
M14942209 is not prime. Res64: 8587C9937E3BED22. We8: CDAD4A41,7713418,00000000
M14942293 is not prime. Res64: 035EFC95F88CFC27. We8: 36084309,4746867,00000000

[Sun Jan 3 22:02:18 2016]
Iteration: 14329935/14942209, ERROR: FFT data has been zeroed!
Possible hardware failure, consult the readme.txt file.
Continuing from last save file.

[Sun Jan 3 22:26:02 2016]
* M14942267 is not prime. Res64: D20C84656405F3FB. We8: FCFDD819,14910347,00000000
= M14942539 is not prime. Res64: 0A930E56A9284971. We8: 7FE55A2A,1188977,00000000
* M14942437 is not prime. Res64: 136153185F4D524F. We8: B81CE272,9576909,00000000
[Sun Jan 3 22:37:01 2016]
* M14942497 is not prime. Res64: 80BD5A064693F1C0. We8: 0CAD30A7,2607443,00000000
= M14942293 is not prime. Res64: 035EFC95F88CFC27. We8: 36502AEF,8394253,00000000
* M14942567 is not prime. Res64: D233F12AC3781E04. We8: 59875C25,3894081,00000000
[Sun Jan 3 22:42:28 2016]
* M14942563 is not prime. Res64: 6815BC39FCD7650F. We8: A94AFB88,2473090,00000000
[Sun Jan 3 22:55:12 2016]
* M14942209 is not prime. Res64: 0AA69D2EA9100E22. We8: 7D077832,14397436,00010000

[Tue Jan 5 10:23:11 2016]
** M14942437 is not prime. Res64: 93143F0CBBAD2FA0. We8: 844CE773,5198729,00000000
== M14942539 is not prime. Res64: 0A930E56A9284971. We8: 7F956974,128927,00000000
** M14942497 is not prime. Res64: CEE4728C3572D92D. We8: CF2E680E,10682871,00000000
=* M14942293 is not prime. Res64: 5F610C0DD3EBDF8B. We8: F9C61BE7,11359273,00000000
[Tue Jan 5 10:30:06 2016]
** M14942267 is not prime. Res64: 493F577EC048F8EF. We8: C3F1DC26,7450471,00000000
** M14942567 is not prime. Res64: 4C77352E05C4856F. We8: 9E995A4B,12435812,00000000
** M14942563 is not prime. Res64: 024A64B503B8470C. We8: CA1DC7AE,4404779,00000000
[Tue Jan 5 10:35:49 2016]
** M14942209 is not prime. Res64: 17C3E50DD9AA888D. We8: 386CCC42,9077154,00000000
[/CODE]

One more way to create errors, see the attached text file, line ending for either windows or Linux.

I first tried to run 8M exponents, which went fine. Then started to work on 9M and ran into troubles.

[QUOTE=tha;421297]One more way to create errors, see the attached text file, line ending for either windows or Linux.

I first tried to run 8M exponents, which went fine. Then started to work on 9M and ran into troubles.[/QUOTE]


This seems to me to be not related to the Skylake bug of this thread, but rather mprime not handling the chances in the worktodo file well under specific circumstances. It continuous at an iteration it shouldn't even if mprime is stopped (option 5 - exit) and restarted (./mprime -m) and the files saved by mprime are deleted in between.

Ah, I now see. mprime added the FFT2=400K to the worktodo file, I did not notice that and when I changed the 8M exponents into 9M exponents I did not take it away.

This small case closed.

[QUOTE=Madpoo;421257]And remember that half the people you meet have below average intelligence. :smile:[/QUOTE]

...and a few are in the top 2% :hello:

I ran two tests today. Both ran 8 separate threads on 4 physical cores concurrently.

The first test ran four exponents in the 2M range in the threads 1 through 4 and four exponents in the 14M range in the threads 5 through 8.

This test run was aborted after the exponents in the 2M range completed.

The second test run consisted of 8 exponents in the 2M range. However in the worktodo file it was specified that they have to run in FFT2=768K mode.

In the first test all four assignments completed successfully. In the second test two assignments failed and 6 completed correctly.

To me this is very eerie similar to the FDIV bug. Most divisions were successful, some failed.

[CODE]
[Tue Jan 5 13:26:31 2016]
= M2000093 is not prime. Res64: D174884B5080EBB8. We8: 79F2D864,1146114,00000000
= M2000147 is not prime. Res64: 934D1CC6B0837C4E. We8: 1FB6A4DD,390140,00000000
= M2000227 is not prime. Res64: F77D1A92737F343C. We8: 36018BA5,348922,00000000
= M2000281 is not prime. Res64: A7D6528C3DFFBD48. We8: B888E4F9,966220,00000000

[Tue Jan 5 18:02:15 2016]
= M2000147 is not prime. Res64: 934D1CC6B0837C4E. We8: 1FBED035,942308,00000000
= M2000353 is not prime. Res64: EEEE1F405891B800. We8: 1A695479,1419216,00000000
= M2000281 is not prime. Res64: A7D6528C3DFFBD48. We8: B8B2A946,553931,00000000
= M2000321 is not prime. Res64: 4E7D677A2432CA95. We8: 2F7E4FC3,1192667,00000000
* M2000227 is not prime. Res64: 8D3112D7CBD7863E. We8: 0412C104,676436,00000000
= M2000381 is not prime. Res64: 97E22ADFEBBA19CA. We8: DD86F310,1479688,00000000
* M2000371 is not prime. Res64: 02075B9EF9ABEE13. We8: A5E56644,1180696,00000000
= M2000093 is not prime. Res64: D174884B5080EBB8. We8: 79E588AA,1846728,00000000
[/CODE]

[QUOTE=Gordon;421306]...and a few are in the top 2% :hello:[/QUOTE]

I assume there are above average fellow mensans around in this forum.
:hello:

[QUOTE=tha;421312]I assume there are above average fellow mensans around in this forum.[/QUOTE]

Statistically likely.... :hello:

ROFL...

So, I had to jump through hoops to get this message posted on the Intel Forum:

[QUOTE]Hi Mike.C. from Intel.

I do hope your engineering department is working this.

You might want to get your public and investor relations departments on this really soon now....[/QUOTE]

That message is "Currently being Moderated".

[QUOTE=chalsall;421339]That message is "Currently being Moderated".[/QUOTE]

Coolness. [URL="https://communities.intel.com/message/361811"]The message was released from moderation.[/URL]

Intel... Please understand. We want to work with you.

But the silence has been deafening.

[QUOTE=Gordon;421306]...and a few are in the top 2% :hello:[/QUOTE]
well, statistically, those are 1 in 50... we don't think we have so many friends... :sad:

Intel has admitted the bug!
 

Great job everyone!

This was posted on the [URL="https://communities.intel.com/thread/96157?start=15&tstart=0"]Intel Forum[/URL] this afternoon by DAVID ORLICH SOLANO, apparently an Intel representative:

[QUOTE]Hello All,

Intel has identified an issue that potentially affects the 6th Gen Intel® Core™ family of products. This issue only occurs under certain complex workload conditions, like those that may be encountered when running applications like Prime95. In those cases, the processor may hang or cause unpredictable system behavior. Intel has identified and released a fix and is working with external business partners to get the fix deployed through BIOS.[/QUOTE]

Yet another example that persistence, and the scientific method, works! :smile:

Edit: Oh, and that George writes _awesome_ code.... :tu:

[QUOTE=chalsall;421422]Great job everyone!

This was posted on the [URL="https://communities.intel.com/thread/96157?start=15&tstart=0"]Intel Forum[/URL] this afternoon by DAVID ORLICH SOLANO, apparently an Intel representative:



Yet another example that persistence, and the scientific method, works! :smile:

Edit: Oh, and that George writes _awesome_ code.... :tu:[/QUOTE]

This is an impressive accomplishment! Thanks and Praises to all who contributed to the knowledge of this bug, and to those who rattled cages to get Intel to pay attention. :tu:

Wow, that went pretty quick and smooth. I was expecting months of battling with them. :)

Well, actually they are pretty reasonable if we can make them see the reason. This turned out very well, for them too, as they can fix it without a recall. Which for me is bad for two reasons, first because I have no skylake, and second, if i would have one, i missed the opportunity to exchange it for a 6990X... :razz:

(still dreaming that i buy an intel cpu which is bad, and it takes months for them to accept it, during which time they still come out with few more powerful/expensive versions, but then they can't fix my bug and recall all, and they make it up to me by replacing it with the best they have, where the bug is fixed, which is 10 times more expensive and 20 times faster... - if you wake me up I will kill you!)

This is a very good result. I will continue to work on a case where we can have prime95 test the CPU for the update having been implemented or not.

I have a version of mprime working that uses no random offset when filling the FFT's. It is working on 8 exponents in the 14M range in 8 threads on 4 cores. When it finishes I will rerun the test and see how the results compare.

I tried this first with 8 exponents in the 3M range, enforcing mprime to use FFT2=768K, but a bit unexpected to me, all 8 results matched the ones in the GIMPS database.

Just to put on the table... I have found it helps if I post a message here which is "Currently being moderated." over on the Intel Forum for it to be released.

[QUOTE]Hello Cesar Badilla

Certainly we will "allow some time" for a response. But is there any chance you could provide an estimate as to how long we should expect to wait? After all, if you (read: Intel) have a fix which is now being rolled out, you should have at least a new MCU.

Please do also note that while it was Prime95 (and _very_ observant testers) which found this bug, there are many who use compute for scientific (and financial et al) purposes which might also exhibit "certain complex workload conditions".

It would be a shame if a lot of previous computing had to be redone, just to make sure the results were correct....[/QUOTE]

[QUOTE=chalsall;421488]Just to put on the table... I have found it helps if I post a message here which is "Currently being moderated." over on the Intel Forum for it to be released.[/QUOTE]

Legitimate questions, but it would be a bigger shame if the info would be out in the wild for everyone to exploit, and the fix would be unavailable. If the advisory matches our expectations I am perfectly OK if that comes out when the BIOS updates are available too.

I wonder if the fix will impact performance.

[QUOTE=tha;421542]If the advisory matches our expectations I am perfectly OK if that comes out when the BIOS updates are available too.[/QUOTE]

This was posted on the [URL="https://communities.intel.com/thread/96157?start=21&tstart=0"]Intel Forum last night[/URL]:[QUOTE]Hello All,

Original equipment manufacturers are aware of issue. In this case please contact the system manufacturer for the latest system BIOS updates.

Regards,

Caesar B_Intel.[/QUOTE]

So it's time for Skylake owners to ask their Mother Board manufacturers for the required BIOS update.

interesting <http://www.ginjfo.com/actualites/composants/processeurs/processeur-skylake-intel-admet-un-bug-et-apporte-une-solution-20160108>

hoping for update soon here: <https://www-ssl.intel.com/content/www/us/en/processors/core/desktop-6th-gen-core-family-spec-update.html>

[QUOTE=Madpoo;421257]And remember that half the people you meet have below average intelligence. :smile:[/QUOTE]

No, half the people you meet have below median intelligence. ;)

Glad Intel appears to have found the problem - I find the whole 'using ever-increasing amounts of microcode to effect post-hoc fixes for hardware bugs' subtheme very interesting, the once-clear line between field-programmable and fixed logic has gotten evermore blurry as chip complexity balloons in accordance with Mr. Moore's famous rule of thumb.

[QUOTE=ewmayer;421598]...the once-clear line between field-programmable and fixed logic has gotten evermore blurry as chip complexity balloons in accordance with Mr. Moore's famous rule of thumb.[/QUOTE]

This is to be expected.

Imagine writing a few _billion_ lines of assembly code, and then not being able to release an update after spending a few billion dollars to release the software....

[QUOTE=ewmayer;421598]No, half the people you meet have below median intelligence. ;)[/QUOTE]
That depends on the typically visited locations. ;)

Beginning to hit the forums and foreign press...
 

Based on the number of "Guest Viewers" it appears this is beginning to be "Out"...

Google shows a couple of popular forums have picked this up, along with two technical press sites (one French, one German).

Only a matter of time now before large news sites start covering this; it's a good thing Intel already have a fix out to their partners.

[QUOTE=chalsall;421831]Based on the number of "Guest Viewers" it appears this is beginning to be "Out"...

Google shows a couple of popular forums have picked this up, along with two technical press sites (one French, one German).

Only a matter of time now before large news sites start covering this; it's a good thing Intel already have a fix out to their partners.[/QUOTE]

Yep. Hitting the tech blogs.
[url]http://www.lifehacker.com.au/2016/01/bug-affecting-intel-skylake-processors-can-freeze-computers-running-complex-workloads/[/url]

[QUOTE=0PolarBearsHere;421855]Yep. Hitting the tech blogs.
[url]http://www.lifehacker.com.au/2016/01/bug-affecting-intel-skylake-processors-can-freeze-computers-running-complex-workloads/[/url][/QUOTE]

If I may please share...

I find it a bit interesting that your linked news source referenced both Scientific and Financial use of compute....

[QUOTE=chalsall;421422]Great job everyone!

Yet another example that persistence, and the scientific method, works! :smile:

Edit: Oh, and that George writes _awesome_ code.... :tu:[/QUOTE]

And special kudos to the German testers that found the problem in the first place. They did an excellent job in eliminating possible causes before bringing it to our attention.

[QUOTE=Prime95;421862]And special kudos to the German testers that found the problem in the first place. They did an excellent job in eliminating possible causes before bringing it to our attention.[/QUOTE]

Indeed. We wouldn't even have realize this was an issue until they brought it to our attention.

The microcode update 0x6A (or higher) should solve the problem. We will see when the new Bios is released.

Hey everyone, so does this only affect Skylake processors with hyperthreading? From my understanding, after reading through the thread, it seems like that's the case however when you read Intel's statement they state it "affects the 6th Gen Intel Core family of products" which makes it sound like every Skylake processor. I ask because I'm running a core i5-6500 (no hyperthreading) and I've completed 13+ hours of small FFT but I always crash after around 6 hours of the blend test. It always seems to be around the 6 hour mark and prime stops responding and then my system is pretty much frozen (can still move cursor around but can't do anything). I first thought it was instability so I didn't take note of the test it crashed at and have been doing a combination of lowering my overclocks/increasing voltage the past couple of runs but it still seems to crash. Right now I'm running it again with my RAM at stock (XMP was on and it had a very slight overclock the past few runs) to see if it still crashes. This time if it does I'll take note of the test it was currently executing.

[url]http://arstechnica.com/gadgets/2016/01/intel-skylake-bug-causes-pcs-to-freeze-during-complex-workloads/[/url]

[QUOTE=Enectic;421911]Hey everyone, so does this only affect Skylake processors with hyperthreading? From my understanding, after reading through the thread, it seems like that's the case however when you read Intel's statement they state it "affects the 6th Gen Intel Core family of products" which makes it sound like every Skylake processor.[/QUOTE]

Those who found the bug, and then those who were able to reproduce it, found that hyperthreading had to be enabled. Also, it only manifested when Prime95 / mprime was running a 768K FFT using the AVX code path.

However, Intel obviously have a much deeper understanding of the issue, so it's possible that other software might encounter the issue without hyperthreading enabled.

What's with the insane number of people viewing this thread over the last few day or so? :surprised:
[code]Currently Active Users Viewing This Thread: 191 (3 members and 188 guests)
[/code]EDIT: Heh new avatar... just noticed :razz:

It's because various press articles are reporting this thread as the original discovery, which while not quite true, is definitely attracting traffic.

[url]http://www.theregister.co.uk/2016/01/11/math_bug_splatters_skylake_intel_working_on_fix/[/url]

[URL]http://winfuture.de/news,90525.html[/URL]
[URL]http://www.computerbase.de/2016-01/prime95-intel-erkennt-stabilitaetsproblem-bei-skylake-cpus-an/[/URL]
[URL]http://www.heise.de/newsticker/meldung/Intels-Skylake-Prozessoren-bleiben-manchmal-haengen-3068461.html[/URL]
[url]http://www.hardwareluxx.de/index.php/news/hardware/prozessoren/37781-skylake-prozessoren-komplexe-berechnungen-koennen-zu-abstuerzen-fuehren.html[/url]

Plot twist: The NSA injects a backdoor into the microcode.

:max:

[QUOTE=Enectic;421911]Hey everyone, so does this only affect Skylake processors with hyperthreading? [/QUOTE]

Try this specific test (except the hyperthreading, and from the screenshot change "number of torture test threads to run" to 4 (instead of 8):
[URL="http://www.mersenneforum.org/showpost.php?p=419502&postcount=184"]post #184[/URL]

[QUOTE=Xyzzy;421954]Plot twist: The NSA injects a backdoor into the microcode.[/QUOTE]

No, it was definitely already there. Who are we kidding...

[QUOTE=Madpoo;421982]No, it was definitely already there. Who are we kidding...[/QUOTE]

Maybe they are the ones secretly doing a lot of anonymous work. Gotta find their big prime numbers somehow.

I was able to replicate this finding for 768k:

i7 6700k @ 4GHz
16 GB Crucial Ballistix Sport (BLS8G4D240FSA.M16FAD) @ 2133 MHz
ASUS M. VIII Hero rev. 1.01 (Bios 1302)

After that my PC froze with 800k.

I know that everybody is convinced that this problem only is with 768k FFT, but I couldn't refrain from sharing it.

pegnose

We all will be indeed surprised if the problem only appears for 768k. This was the easiest way to pop the mushroom, but if they have some threading synchronization problem, or whatever else, the problem should appear for other sizes too, and for other programs too. Just that the "kicking frequency" of those other sizes and other programs didn't "resonate" with the bug, so the chances to spot it were lower.

The new Bios was released today. We will see if it solves the problem.

In the news>
[QUOTE]Intel Skylake bug causes PCs to freeze during complex workloads
Ars Technica-Jan 11, 2016
Discovered by mathematicians at the Great Internet Mersenne Prime Search (GIMPS), the bug occurs when using the GIMPS Prime95 ...

Intel Skylake-based PCs freeze during complex workloads
BetaNews-7 hours ago

Is it better to freeze or give bad results? Skylake and complex math ...
PC Perspectives-20 hours ago

Intel confirms Skylake crash erratum
bit-tech.net-Jan 11, 2016

Prime95 can cause Intel Skylake CPUs to freeze
Highly Cited-The Tech Report, LLC-Jan 11, 2016

How to test your PC for the Skylake bug
In-Depth-PCWorld-19 hours ago

More articles (46)[/QUOTE]

It's out there everywhere now... just google "skylake freeze"

Seems as the new MC solves the problem: [url]http://www.bilder-hochladen.net/files/big/hb0a-a3-8e76.jpg[/url]

[QUOTE=Aurum;422069]Seems as the new MC solves the problem: [url]http://www.bilder-hochladen.net/files/big/hb0a-a3-8e76.jpg[/url][/QUOTE]

Fantastic!!! :tu:

Two quick questions if I may... How long have you let this test run for, and what motherboard are you using?

[QUOTE=chalsall;422080]…and what motherboard are you using?[/QUOTE]His picture shows "ASRock".

:mike:

[QUOTE=Xyzzy;422086]His picture shows "ASRock".[/QUOTE]

:doh!:

I have new glasses on order... (I'm not joking.)

[QUOTE=chalsall;422080] How long have you let this test run for, [/QUOTE]

10+ hours (prime is still running) ...


[QUOTE=chalsall;422080] and what motherboard are you using?[/QUOTE]

ASRock Z170 OC Formula

Has the performance changed? The benchmark in Prime95 would be a good tool to use to see. Thanks!

[QUOTE=willmore;422103]Has the performance changed? The benchmark in Prime95 would be a good tool to use to see. Thanks![/QUOTE]

But that only works against a baseline.

willmore, perhaps we could ask you to run a bunch of tests before the upgrade, and then run a bunch of tests after the upgrade, and see how they compare?

[QUOTE=Aurum;422099]10+ hours (prime is still running) ...[/QUOTE]

Sweet! I would give it 24 hours just to be sure, but it looks like you guys found a true bug that Intel took seriously.

As George said, kudos to you and your associates.

You guys found this bug; we were just the support crew. :smile:

MSI team don't send me a beta bios including the microcode but rather tell me to wait for the next bios release :down:

[QUOTE=Phil MjX;422117]MSI team don't send me a beta bios including the microcode but rather tell me to wait for the next bios release :down:[/QUOTE]

Would do me a favor and run the benchmark inside of Prime95 before and after? There are a lot of people curious if this fix will have a performance penalty. Too many bad memories from Barcelona.

chalsall, I wish I could run Sky Lake benchmarks! My newest box is Ivy Bridge. :(

[QUOTE=willmore;422123]chalsal, I wish I could run Sky Lake benchmarks! My newest box is Ivy Bridge. :([/QUOTE]

It's chalsall. And if you can't run your own tests under Skylake then pay people to run the tests you want.

[QUOTE=chalsall;422080]Fantastic!!! :tu:

Two quick questions if I may... How long have you let this test run for, and what motherboard are you using?[/QUOTE]
More important question: do you see any performance hit when you run the "more stable" newer version? (like they waiting for threads sync internally, or so, to cheat the bug, etc)

[QUOTE=LaurV;422162]More important question: do you see any performance hit when you run the "more stable" newer version? (like they waiting for threads sync internally, or so, to cheat the bug, etc)[/QUOTE]

I had that same idea:
[QUOTE=willmore;422103]Has the performance changed? The benchmark in Prime95 would be a good tool to use to see. Thanks! [/QUOTE]

[QUOTE=willmore;422123]Would do me a favor and run the benchmark inside of Prime95 before and after? There are a lot of people curious if this fix will have a performance penalty. Too many bad memories from Barcelona.[/QUOTE]

But chalsall suggests I should buy my own SkyLake system to test:
[QUOTE=chalsall;422126]It's chalsall. And if you can't run your own tests under Skylake then pay people to run the tests you want. [/QUOTE]

Maybe we should pool our pennies?

Some of the things that chalsall says, while well intentioned, are... a bit misplaced, shall we say. On this particular tidbit of conversation, it's best ignored, I think.

[QUOTE=willmore;422164]I had that same idea:
But chalsall suggests I should buy my own SkyLake system to test:
[/QUOTE]
Haha, don't take it to your heart, he is just sad that it wasn't him who found the new prime, but I am telling him for ages: if he only does DC tests, he can't be the first to find the prime! :razz:

About the idea, you are right, sorry, when I posted I didn't read all the posts to the end of the thread, due to page(s) switching. I still consider that I am entitled to an answer, and buying the Skylake (which Chris suggested), may depend (or not) of that answer. :smile:

So, Aurum? :sos:

[QUOTE] Maybe we should pool our pennies?[/QUOTE]How can we do that remotely? I mean I can not pull yours and you can not pull mine. So, can we try each one with his own peni's?... :w00t:

[QUOTE=LaurV;422025]We all will be indeed surprised if the problem only appears for 768k. This was the easiest way to pop the mushroom, but if they have some threading synchronization problem, or whatever else, the problem should appear for other sizes too, and for other programs too. Just that the "kicking frequency" of those other sizes and other programs didn't "resonate" with the bug, so the chances to spot it were lower.[/QUOTE]

I see, thanks.

Would I see this problem during gaming, as well? Interestingly not every game, but then it is a rare phenomenon: my PC will just freeze during gaming (just once a week or so). Seems to be more often with Win10 than Win7 though. I even believe that it didn't happen at all with the first Bios I had (202 or something). Sometimes the ASUS Q-Code says '02' then.

I wasn't able to provoke this with
- regular Prime95 settings (FM3: 800k, 1344k)
- Furmark or other GPU stress tests
- memtest86 (I had some issues here, but after raising the Dram power tolerance to 110%, the ram was stable 24/7)
Nothing is overclocked at the moment and no temp issues are visible (CPU<60°C, GPU<70°C)

So I was quite puzzled until I read about this bug. And ASUS support didn't tell me anything about it but let me keep on searching and testing... (good job, guys).

[QUOTE=pegnose;422182]Would I see this problem during gaming, as well? [/QUOTE]

We don't know. Intel was not very forthcoming in describing what the problem was and/or what programs might be affected.

Ok, thank you. I just ask because the experienced testers here said they didn't have any trouble whatsoever with other settings then AVX FFTs with 768k. So if I take them by their word, my issue must be a different one. I was hoping that some of those could tell me that they had issues with other test constellations, but only less frequently.

[QUOTE=pegnose;422182]
I wasn't able to provoke this with
- regular Prime95 settings (FM3: 800k, 1344k)[/QUOTE]

With Prime95 version 28, you need to disable AV2/FMA3 support. (v27 has no such support and tends to fail faster, empirically.) Then set the torture test to use in place 768K FFTs.

I know. I only stated what I did before.

As I got the freeze with 800k ('AVX) as well in roughly the same amount of time, I am trying to figure out, whether it might be something else. That's why I am asking some questions. I understand that only Intel can have all the answers. I particularly asked about gaming because I read that this issue only shows with very large numbers. Would some DirectX Games compute such large numbers - not very likely. Would they use AVX over FM3, if at all, maybe when they are a bit older? Who knows.

I am just trying to solve my problem. It is a) the eventual freeze, and b) that I have a software raid running which needs to rebuild for ~1 day after such an incidence - which is not so nice. I am trying to figure out whether I have to keep on looking. That's why I am bugging you with my stupid user questions.

Thanks for bearing with me.

Ah yes of course, my apologies.

As for your current problem, yes I'm afraid we've done what we can. Until Intel releases details of the bug or you get the bios update and test, we won't really know for sure.

Real world
 

Very nervous about all I am seeing over the net. I decided to run a few prime tests using the parameters on here [URL="http://www.pcworld.com/article/3021023/hardware/how-to-test-your-pc-for-the-skylake-bug.html%23tk.rss_all"][COLOR=#0066cc]How to test your PC for the Skylake bug | PCWorld[/COLOR][/URL] and created the local.txt file as instructed. I couldn't reproduce it in the spare time I had yesterday evening.

I only done about 30 minutes a time but I got no errors or freeze using my 6700k. Maybe it would of done after a few hours but I didn't want to stress the cpu (although at stock clock) at 100% for hours and hours. It cost too much money to take risks!!! Maybe not all skylakes are affected and I got lucky (has anyone failed to reproduce it with a skylake processor despite repeated testing)? Like the other poster I am keen to ascertain whether in real world usage like browsing, gaming, using office, ripping my dvd collection, iTunes. Am I really likely to encounter this bug (if it exists on my cpu)? I've had the system almost 3 months and never had a freezing issue.

I really would want to avoid a risky BIOS update (mobo is ASUS Z170 PRO GAMING: ATX, LG1151, USB 3.1, SATA 6GBs). I did one years ago on an old laptop and it didn't go well!!!

Cheers,
Wayne

That's a very nice article! They mention the original forum as well, and nothing but facts. Kudos to PCWorld.

In our tests here, it was indeed a sporadic bug that doesn't affect even all 6700Ks -- it's entirely possible yours is simply unaffected. Web browsing and iTunes, etc, are very unlikely to produce the bug -- as we understand it, only truly running your CPU at load, for example with Prime95, will create likely conditions for the hang to appear. Gaming is a possibility, though unlikely and no reproducible reports of such.

As for running at 100% for hours and hours, at stock voltages and frequencies, that's what tens of thousands of GIMPSters do every day, and what hundreds-of-thousands or even millions of similar CPUs used for scientific, engineering, and research purposes do every day. The CPU is defective if it cannot withstand continual usage (at stock voltages and frequencies!).

In this case, as in nearly every case, if it aint broke, don't fix it. You're not using your CPU for number crunching purposes, and it hasn't crashed, so it doesn't seem necessary to update your bios.

Thank you
 

Thank you, sometimes it just takes someone with a cool head to make things seem better. I am probably over stressing about it. I will run some longer tests and see what comes out. But I think your 'ain't broke, don't fix it' comment makes perfect sense. I won't touch the BIOS (I've never enjoyed 'updates' whether it be windows updates, BIOS or even GPU) unless there is a compelling need to do so!

Cheers,
Wayne

24h 768K: [url]http://www.bilder-hochladen.net/files/big/hb0a-a4-1676.jpg[/url] I think the MC 0x6A (or higher) solves the problem.

[QUOTE=Scottyboy99;422200]Very nervous about all I am seeing over the net. I decided to run a few prime tests using the parameters on here [URL="http://www.pcworld.com/article/3021023/hardware/how-to-test-your-pc-for-the-skylake-bug.html%23tk.rss_all"][COLOR=#0066cc]How to test your PC for the Skylake bug | PCWorld[/COLOR][/URL] and created the local.txt file as instructed. I couldn't reproduce it in the spare time I had yesterday evening.[/QUOTE]

Try using Prime95 version 27.9: [URL="ftp://mersenne.org/gimps/p95v279.win64.zip"]ftp://mersenne.org/gimps/p95v279.win64.zip[/URL]
The people testing reported the bug appeared faster in that version. You do not need any local.txt for this version but run the same 768K tests on 8 threads and for at least a few hours to be reasonably sure.

[QUOTE=pegnose;422191]I particularly asked about gaming because I read that this issue only shows with very large numbers.[/QUOTE]
The CPU can not operate with numbers bigger than 2^64, that is why it is a "64-bit" processor. Well, there are exceptions where the results of some operations are on 80 or 128 bits, etc., but here "very large numbers" means a lot of "small" numbers put together, same way as one uses 10 figures (from 0 to 9) to write very big numbers, and multiply them digit by digit. Here we have more "digits" (up to 2^30 or so) and put them together to form those big numbers. No matter if "big numbers" are involved, or "big images on screen" or "big gaming strategy", the CPU still uses a lot of small numbers, doing a lot of tricks (operations) with them, very fast, like a super-juggler. Sometimes he loses the track, and one plate falls to the floor in pieces. Or a glass, or something... But big numbers or not, only the timing and "keeping track" is important.

No matter if you run Prime 95, or other program, or play your favorite game, they all move glasses and dishes and 64 bit integers from here to there, they do nothing else, sometimes creating them and destroying them in the process. Your program can stress the CPU no matter if is a game or not, if it is built to do so, "big numbers" are not necessary. They are just the "monsters" you see when you play zergs, or whatever, but they all, big numbers and zergs, are done from many-many small numbers.

Thanks for the clarifications, guys! So it seems possible that I experience this bug during gaming. Particularly, as I have ruled out nearly every other option. But it happens only occasionally, fitting your notion, Dubslow. In any way I will hold my horses for now and wait for the patch to see if the problem persists.

Regarding "not all skylakes...": I am pretty sure that I had no freezes during my first 1.5 months or so. At some point of time, however, I did a bios update because I had some issues with an onboard Sata controller (the driver crashed during Speedfan startup). Of course, the bios update didn't solve the issue. But maybe it brought the bug? ;)

What I would like to ask: some people reported a freeze with the 768k test and some reported that Prime95 gave a "hardware error". What's with that difference?

[QUOTE=Aurum;422212]24h 768K: [URL]http://www.bilder-hochladen.net/files/big/hb0a-a4-1676.jpg[/URL] I think the MC 0x6A (or higher) solves the problem.[/QUOTE]

??? Microcode update 0x6A is already out and dated 14-Dec-2015.

That's correct. The bug was reported in November (16-Nov-2015). Seems as if there will be another Microcode update later this month.

What is correct exactly, that version 0x6A provides a fix for the bug? I'm a little confused since AFAIK correspondence didn't start with Intel until 16th Dec and Intel only acknowledged a fix in January. Your posts suggest version 0x6A provides a fix.

[QUOTE=Aurum;422375]That's correct. The bug was reported in November (16-Nov-2015). Seems as if there will be another Microcode update later this month.[/QUOTE]

I had a hunch that might have been the case. I can't remember if I read it on the Intel forum or somewhere else, but it sounded like they were able to replicate the problem by rolling *back* from their internal microcode release they were using.

Which would imply exactly that... it had been fixed already but not released publicly.

Maybe I'm reading those tea leaves wrong, but that would make sense.

Where in this picture is the "6A"?

[QUOTE=Madpoo;422417]I had a hunch that might have been the case. I can't remember if I read it on the Intel forum or somewhere else, but it sounded like they were able to replicate the problem by rolling *back* from their internal microcode release they were using.[/QUOTE]

It was in this [URL="http://mersenneforum.org/showpost.php?p=419446&postcount=171"]post[/URL] in this thread.

Specifically, a PM or an email sent to "tha" via back-channels when people at Intel first starting getting interested in this issue.

[QUOTE=Dubslow;422166]Some of the things that chalsall says, while well intentioned, are... a bit misplaced, shall we say. On this particular tidbit of conversation, it's best ignored, I think.[/QUOTE]

Just now reading back to this...

Yes, please feel free to ignore me. I often make stupid statements and stupid mistakes.

My goal is to be at least 50% useful....

[QUOTE=chalsall;422489]Just now reading back to this...

Yes, please feel free to ignore me. I often make stupid statements and stupid mistakes.

[B]My goal is to be at least 50% useful..[/B]..[/QUOTE]

I have a sneaking suspicion that you accomplish this goal. Occasional crabbiness is to be expected in times of stress. :smile:

[QUOTE=kladner;422495]I have a sneaking suspicion that you accomplish this goal.[/QUOTE]

Thanks. But please don't blow sunshine.

Where I came from if one don't make the grade one is blown out the airlock without ceremony...

(That's meant to be funny, and serious, at the same time.)

[QUOTE=chalsall;422501]Thanks. But please don't blow sunshine.

Where I came from if one don't make the grade one is blown out the airlock without ceremony...

(That's meant to be funny, and serious, at the same time.)[/QUOTE]
Comprendo.

Y yo también comprendo, pero sometimes it's not so clear to newcomers.

[QUOTE=chalsall;422485]It was in this [URL="http://mersenneforum.org/showpost.php?p=419446&postcount=171"]post[/URL] in this thread.[/QUOTE]

Thank you chalsall. In the meantime people can use the previously attached [url=http://mersenneforum.org/showpost.php?p=422335&postcount=368]mcupdate 0x6A[/url] to update their system either through BIOS firmware modification or using software at the OS level while waiting for the manufacturers fix.

[QUOTE=Zero;422511]Thank you chalsall. In the meantime people can use the previously attached [URL="http://mersenneforum.org/showpost.php?p=422335&postcount=368"]mcupdate 0x6A[/URL] to update their system either through BIOS firmware modification or using software at the OS level while waiting for the manufacturers fix.[/QUOTE]
Or better get it from the source?
(not that I say yours is not clean, but if I would want to upgrade my bios, I won't take ROMs posted by some/any/body, some/any/where, that just to avoid further "discussions") :smile:.

Not to mention this forum doesn't (yet) use HTTPS.

[QUOTE=chalsall;422485]It was in this [URL="http://mersenneforum.org/showpost.php?p=419446&postcount=171"]post[/URL] in this thread.

Specifically, a PM or an email sent to "tha" via back-channels when people at Intel first starting getting interested in this issue.[/QUOTE]


Alright! Sorry, I had even read that. But what I particularly meant was "in the linked image". Because my CPUID is the same and I still got the freeze.

So:
a) How to exactly identity your microcode?
b) Where to get it from source?
c) What if Bios version won't want to play with rolled-back MC version?
d) What's wrong with "Let's encrypt?" :)

Ok, so you can find out microcode version e.g. with Sisoft Sandra.

Also, this might be interesting for some, suggesting that version A6 won't fix the issue completely:

[url]http://www.overclock.net/t/1568154/asus-north-america-asus-z170-motherboards-q-a-thread/2960#post_24786280[/url]

[QUOTE=pegnose;422577]Ok, so you can find out microcode version e.g. with Sisoft Sandra.[/QUOTE]

Be inquisitive. Run tests.

Testing what?

Just wanted to say that I was lazy (apologies) and finally answered my own question.

EDIT: In case you mean for the Skylake/768k bug: I did, but I get a freeze and no worker error. I already asked here about this difference, but gut no answer.

[QUOTE=pegnose;422580]I already asked here about this difference, but gut no answer.[/QUOTE]

Gut no answer?

Oopsie.

Re-reading this thread...

others have experienced freezes as well, which seem to be cured by bios 1402:
[url]http://www.mersenneforum.org/showpost.php?p=420747&postcount=206[/url]

But it is discussed to be indicative of different bug:
[url]http://www.mersenneforum.org/showpost.php?p=420954&postcount=256[/url]