[QUOTE=Phil MjX;418949]And indeed with prime95 v27.9 I got failures overnight, the 1st one after 1 hour and an half !

My configuration :

intel 6700K @ 4.5 GhZ + enermax watercooling kit
MSI gaming M7
SSD samsung 850 EVO
2x16 Gb Corsair low profile @ 3 GHz
inno3D GTX970 superclocked
Alim enermax platinium 850w


I'll try again with stock frequencies but my cpu ran stable with mixed fft lenghts for hours. It also pass Linpack stress test for hours.
[/QUOTE]

FYI, the folks who first reported it here have done all kinds of tests on their systems with overclocking, underclocking, etc. and the issue seemed to be unrelated to any of that. You could try the same on your system just to confirm, but you'll probably still get the same result even if you underclock your system.

[QUOTE=Phil MjX;418952]My 20 months daughter tends to shut down (and up and down...) my computer as soon as she is awaken but I'll give a try.[/QUOTE]

Remember to disable FMA when testing with version 28.7.

Add this to your local.txt file:
CpuSupportsFMA3=0

Thank you, I have done this while testing v28.7 and FMA3 was disabled.
I can post the log files for comparison purposes, but it seems quite pointless to me.

With 27.9, at 4.0 Ghz factory clock speed for CPU, default voltage and default 2133 Mhz for RAM (a 3000 Mhz Corsair Vengeance set) I have the same failures than with the overclocked config, and even faster...

I'll try again v28.7 with these clock rates but the problem seems to pop much faster with v29.7 of prime95.

I'll also contact MSI support tomorrow.
Does it seems relevant if I give a link to this forum thread in my mail ?

Philippe

[QUOTE=Phil MjX;419081]
I'll also contact MSI support tomorrow.
Does it seems relevant if I give a link to this forum thread in my mail ?
[/QUOTE]

I would say so. I would also think that mentioning "ASRock boards are known to also suffer, and they have contacted Intel; the more OEMs that contact Intel, the better" would be good as well. Show them they're not alone, it's not their fault, they just need to get corporate contact involved.

[QUOTE=Phil MjX;419081]I'll also contact MSI support tomorrow.[/QUOTE]

Thank you very much for doing this. The larger the sample set (and different motherboard motherboards exhibiting the same behaviour are very important) the better.

If possible, could you determine the batch and/or manufacture date and/or the serial number of your CPU? This would be good to report to MSI / Intel as well.

This is getting _really_ interesting....

[QUOTE=chalsall;419086]...This is getting _really_ interesting....[/QUOTE]

I've been puzzling over potential reasons why disabling HT makes it better.

Googling "skylake hyperthread changes" tells me that there's speculation out there that Intel implemented some form of "inverse hyperthreading" where it can make multiple physical cores of the CPU appear as one core as far as a program is concerned.

The end goal being to get performance gains out of non-threaded apps.

Maybe disabling HT in the BIOS also disables that "inverse HT" feature. On an app that's already threading things, that feature could do strange things. And that torture test will keep all physical and HT cores super busy so it would really make things even more interesting. And, again just theorizing, maybe this inverse HT only shows weird things at the 768K FFT size, perhaps because of the amount of memory involved or something weird.

That's one reason why if I had access to a Skylake chip, I'd want to go beyond just the torture test and run a real world 768K FFT test with varying numbers of cores in the worker.

With all physical cores in one worker (no HT cores) and doing a test of something in that FFT size, would it still give roundoff errors? And then have it use the HT cores too?

Or would it only show up if you're running multiple workers, each with one core and just running them all simultaneously (like the torture test does)?

There's a big difference between 1 worker running 4 (or 8) threads, or 4/8 workers with one thread apiece, and I haven't seen that anybody has done the comparison yet?

Reverse hyperthreading is very likely not used by Intel.

OTOH when HT is enabled some hardware resources are statically (at reset) or dynamically (at runtime) split which certainly changes the way the chip behaves.

Dear all,
I have posted this mail on MSI support service with my Mobo fully registered.

[QUOTE]
Hello,

I use my computer mostly for scientific purposes.
The computer fails to pass well known prime95 torture test v27.9 with a very specific parameters combination.

This is discussed on the forum of prime95 in this thread :
"768k Skylake Problem/Bug"
[url]http://www.mersenneforum.org/showthread.php?t=20714[/url]

Different combinations of Skylake CPU/mobo seems affected, mostly with ASRock,but with MSI too since I contact you, at manufacturer clock speeds for cpu and RAM.

A lot of things have been tried to eliminate ram problems or specific components failures on the forum.

Prime95 is a well known program, used for years to discover world record primes and also to stress test cpu's.
The problem is occuring in 2 different versions of the program using differents algorithms.

I am worried about the reliability of my system and about the possibility of a bug in CPU/chipset architecture.

I am confident that MSI motherboards aren't directly involved but it seems important to me that MSI, and other OEM manufacturers, can have corporate contacts with Intel to evaluate the problem.

Could you please keep me informed?

Regards,[/QUOTE]

Sorry for my bad english, I'll keep you informed (if they keep me informed too :smile:).

Regards,
Philippe

[QUOTE=ldesnogu;419137]Reverse hyperthreading is very likely not used by Intel.[/QUOTE]

I thought it was a bit speculative myself when I was reading about the Skylake theories, but anyway, those discussions are out there. Apparently the same theories came out a decade ago with some AMD processor or another, and ended up being wrong. :smile:

[QUOTE=AGM;418761]Yes, many of us use an OCF, simply because its a very good OC board. It was one of the first things we thought might be the cause. Then people with MSI, Gigabyte and Asus boards noticed the same problem.
I think that was mentioned already. ;)[/QUOTE]

OK, we now have an independent tester with an MSI MB which has confirmed the results you've reported. They've reported it to the MB manufacturer.

Could those of you with Gigabyte and Asus motherboards please report your results here and/or to your respective MB manufacturers? Failures are critical, but successes are important too.

There is a non-zero probability that this is a true CPU bug.

And, to be clear, this could actually be really important for science. After all, Intel chips are in many leading edge supercomputers. I'll leave the financial ramification for others to think about....

[QUOTE=Phil MjX;419177]Dear all,
I have posted this mail on MSI support service with my Mobo fully registered.



Sorry for my bad english, I'll keep you informed (if they keep me informed too :smile:).

Regards,
Philippe[/QUOTE]
Your English usage probably outshines that of most US folk.

I think your statement is cogent, organized, and very well expressed. You hit some important points, such as mentioning scientific use of your computer, and also that you are not accusing MSI of causing the problem. You were detailed as to the testing which has been done.

Well Done, Sir!