Re: Intel's Skylake Prime Number Bug.

Probably tweaks the microcode as the system boots to fix the problem.

Or trap the failing instruction and emulate it.

Can anybody translate that?

On Mon, 11 Jan 2016 20:35:55 -0800, John Larkin Gave us:

CPU level instructions are at the API level. The question is can YOU translate it.

hahaha, that was fun. :)

joe

It is just the usual random word salad you expect from that poster.

A few more details on how to reproduce the problem which seems to be related to a very highly optimised handcoded assembler FFT core of length 768 at the heart of the Mersenne prime project is online here.

Quoting from that page:

]Steps to freeze your Skylake system: ] ]- Download and install Prime95 for Windows on a Skylake system from the website at

Or a for second take on the same issue:

This one might also be relevant as the Skylake i7 6700 seems to have an unexpected performance signature when compared to a Haswell i7 4790:

Intel don't say how they propose to fix it in detail but it appears to be related to AVX & hyperthreading of very compact bandwidth hungry hand crafted assembler code so it could be anything from a speculative execution bug to noise or a memory timing glitch under extreme loading.

What is certain is that a particular number input to Prime95 kills that CPU after a random time which seems to depend on wind direction...

In ordinary computational software it probably doesn't matter but anyone using AVX and hyperthreading in heavy scientific computations on Skylake would be well advised to recompute and check some of their work in single threaded mode and/or without using AVX parallelism.

Your mother must have fed you s*it salad all of your life.

On Tue, 12 Jan 2016 09:11:54 +0000, Martin Brown Gave us:

Oh, you mean assembler... that 'stuff' that uses the CPU's API, just like I mentioned.

You and John should run out together and have a s*it salad lunch.

Need more translation.

The old Pentium FPP bug would lock up the CPU if you just divided the wrong pair of floats.

Microcode patches are often done in RAM. BIOS loads the patches every reset.

No it didn't.

Intel Pentium FDIV bug in 1994 produced values that were typically wrong by a few tens of ppm for about 1 in 10^10 of all possible inputs. I actually had one of the failing CPUs on the bench to test.

The F00F bug 1997 was a bit more dangerous but even that wasn't a show stopper. It was the closest they ever came to an HCF instruction. (Halt and Catch Fire) Intel took a lot of flak for how it handled both.

I still have a key fob made out of a defective previous generation Intel chip given to me in Japan - it has lasted very well.

Cyrix were not immune either they had an HCF bug of their own in 1997 involving a hidden bus locking instruction pattern that halted execution by locking out all interrupts until the system was rebooted.

It was found in the early days of pipelines and branch prediction.

I wrote a little test app in turbo pascal to show the failure..

I don't remember the math but there was a ???/256 in volved that caused the error.

Jamie

James has pointed out that the old purple ceramic 486 chips make excellent x-acto knife sharpeners.

OK, that one just made math errors. Intel is making progress!

I had one of those, and had a program in Turbo Pascal 3 I think that clearly illustrated the problem. The computer maker (Gateway) stonewalled me until Intel agreed to take the hit for all the customers. Never bought anything else from Gateway.

--sp