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....