Solution : reason for failing conroes at prime

[realsmasher]

Some people have issues with prime in-place ftt or spi 1.4 (not 1.5). failing after seconds was common for a few of us.

now intel released a pdf with bugs of the stepping 6 conroes and there is the solution :

http://download.intel.com/design/pro...t/31327902.pdf

FP Inexact-Result Exception Flag May Not Be Set

so prime/spi 1.4 only fail for rounding error cause the flag is not set, but not cause it's really a false result.

many people noticed that this error only appears on several bios-versions or asyncron running ram. now this COULD also be related or it's a combined effect, i really don't know.

but the more interesting thing is : will this flag make problems in real computer use or only for stability testing purposes ?

anyway, now we have some kind of answer. hope this takes a bit of confusion from your minds, as it did for me

[Frackal]

Sweet, I'm abandoning Prime entirely! 4ghz air here we come!


(JK)

Interesting though. So how might we know if the error is this vs. regular, real rounding errors?

[Revv23]

yeah i remember early AMD winchesters were doing something similar, they would faiil prime even at stock speeds sometimes, but there wasnt any realy problem with the cpu's.

[Reite]

Damn, anyway for them to fix that with bios change or do they need to fix the chip itself?

[korruptedone]

Hmmmm....time to try for 3.4 gig on my E6400 then....dirty dirty prime I knew my chip had more room!

Maybe not...we'll see.

[LexDiamonds]

Damn, anyway for them to fix that with bios change or do they need to fix the chip itself?

If this is part of the same errata list that was recently released, word is that they are releasing a new stepping to fix the problems.

Also keep in mind that Intel pushed up the release of C2D a couple of months, so a small mixup like this is not entirely unexpected.

Of course for day to day use, no one will notice one way or another.

[lopri]

Solution for Prime failing Conroes?

Lower the OC by 200MHz.

But on more serious note, I tend to notice some inconsistency with 4MB L2 chips.

[toledo]

yeah i remember early AMD winchesters were doing something similar, they would faiil prime even at stock speeds sometimes, but there wasnt any realy problem with the cpu's.

If they are failing doing calculations it is a problem ... i use this stuff to work i don't want it to produce wrong results in calculations .

[Btrice]

If they are failing doing calculations it is a problem ... i use this stuff to work i don't want it to produce wrong results in calculations .

Well I basically got mine for the same reason. I am putting my work program (home grown Fortran simulation that makes this Prime stuff look like calc.exe) on tonight, if you want I could let you know if the results are the same as I get on my work machines and laptop. I seriously doubt they will be different, at the worst I think it just won't run (in my mind erroneous results are worse than no results at all).

[Brahmzy]

Funny enough, with my E6600...I almost don't need Prime...I just run 3DMark05 and when it gets to the first CPU test, it'll reboot if the OC's too high and it won't if it's not. For me, if it passes those 3DMark CPU tests, it'll pass Prime for over 12 hours, EVERY time. Down to the 1MHz detail.

Very strange.

[Plaicd]

Seems to me if it was a prime failure because of this cpu bug then it would fail at stock speed too.

[Btrice]

Seems to me if it was a prime failure because of this cpu bug then it would fail at stock speed too.

*snipped for my stupidity*

Has anybody bothered to run prime at stock on the current stepping?

[mds47]

Is this the bug you're referring too?

I think the problem is the FPU isn't setting a "roundoff has occured" flag on calculations which required a roundoff and have an immediate store to memory. (btw roundoff occur all the time, floating point is only so accurate). So the effect is practically zero on gaming and general applications. If you're running some banking or scientific software (or torture test software) that needs to know if a roundoff occured you're in trouble.

Looks like theres a fairly do-able work around in software though. Just need a disassembler. Add a couple NOOPs before the floating point store instructions.

Then we could test stability with this known precision bug out of the equation.

mds

-------

AI20. FP Inexact-Result Exception Flag May Not Be Set

Problem:
When the result of a floating-point operation is not exactly representable in the destination format (1/3 in binary form, for example), an inexact-result (precision) exception occurs. When this occurs, the PE bit (bit 5 of the FPU status word) is normally set by the processor. Under certain rare conditions, this bit may not be set when this rounding occurs. However, other actions taken by the processor (invoking the software exception handler if the exception is unmasked) are not affected. This erratum can only occur if one of the following FST instructions is one or two instructions after the floatingpoint operation which causes the precision exception:

• FST m32real
• FST m64real
• FSTP m32real
• FSTP m64real
• FSTP m80real
• FIST m16int
• FIST m32int
• FISTP m16int
• FISTP m32int
• FISTP m64int
• FISTTP m16int
• FISTTP m32int
• FISTTP m64int

Note that even if this combination of instructions is encountered, there is also a dependency on the internal pipelining and execution state of both instructions in the processor.

Implication: Inexact-result exceptions are commonly masked or ignored by applications, as it happens frequently, and produces a rounded result acceptable to most applications. The PE bit of the FPU status word may not always be set upon receiving an inexact-result exception. Thus, if these exceptions are unmasked, a floating-point error exception handler may not recognize that a precision exception occurred. Note that this is a "sticky" bit, i.e., once set by an inexact-result condition, it remains set until cleared by software.

Workaround: This condition can be avoided by inserting three non-floating-point instructions between the two floating-point instructions.

Status:
For the steppings affected, see the Summary Tables of Changes.

The Specification Changes listed in this section apply to the following documents:

• Intel® Core™2 Extreme Processor X6800 and Intel® Core™2 Duo Desktop Processor E6000 Sequence
• IA-32 Intel® Architecture Software Developer’s Manual volumes 1,2A, 2B, 3A, and 3B

All Specification Changes will be incorporated into a future version of the appropriate Intel® Core™2 Extreme and Intel® Core™2 Duo Desktop Processor documentation.

[Fred_Pohl]

Has anyone ever seen a Prime rounding error on a stock C2D? I've only seen them occur at 400+FSB with large FFTs on my E6400. Right now I'm 15+ hours into Orthos large FFT testing at 376FSB without any errors.

[toledo]

Well I basically got mine for the same reason. I am putting my work program (home grown Fortran simulation that makes this Prime stuff look like calc.exe) on tonight, if you want I could let you know if the results are the same as I get on my work machines and laptop. I seriously doubt they will be different, at the worst I think it just won't run (in my mind erroneous results are worse than no results at all).

Great . Let me know your results as soon as possible .... . You can post here , i bet i am not the only one who is worried about it .

[kiwi]

Don't say you are overclocking and making serious computations then

[sombrio]

Seems to me if it was a prime failure because of this cpu bug then it would fail at stock speed too.

Exactly.

[realsmasher]

ok for you people that don't know it and tell funny stuff now, i'll explain it :

even on stock clock and voltage(or even higher voltage) large-in-place-ftt-prime would fall and also spi 1.4

NOTHING OC and NO lower voltage.

so if you fall only when OC, this cpu-bug is NOT what you got !

to test stability just use blend or small-ftt, cause this works perfectly(at least for me) as it don't uses this flag.

[lawrywild]

You say solution but I don't see any solution in this thread

All you've done is listed what Intel have said is a bug..

[uOpt]

I am sorry guys, but this has nothing to do with the issue. The Intel bug is the other way round.

MPrime and SuperPi fail because they get the not exact rounding flag.

This CPU bug is that sometimes this flag is not set when it should be.

And yes it is probably meaningless for even math applications as it will still give a correctly rounded result - just not properly declare whether it was rounded or not. Most applications continue with the rounded result anyway and it is the same, flag or not. But this bug means strict IEEE compliance is not met.

[pcdoc1]

This is an excellent thread for people that can't get stable enough to complete prime... It's just one more excuse in the arsenal…

[mds47]

I am sorry guys, but this has nothing to do with the issue. The Intel bug is the other way round.

MPrime and SuperPi fail because they get the not exact rounding flag.

This CPU bug is that sometimes this flag is not set when it should be.

And yes it is probably meaningless for even math applications as it will still give a correctly rounded result - just not properly declare whether it was rounded or not. Most applications continue with the rounded result anyway and it is the same, flag or not. But this bug means strict IEEE compliance is not met.

Are you sure about this? I have the prime95 source but havent look at this in detail yet.

My intuition is the check is done on results that were not flagged as rounded by the fpu. In other words the value should be exact (unless overclocked error) and comparable to a known exact value.

If the "roundoff occurred" flag isnt getting set from this bug, the algorithms may be checking results that were indeed rounded with perfect values to detect instability (which does not necessarily indicate instability).

mds

[uOpt]

Are you sure about this? I have the prime95 source but havent look at this in detail yet.

My intuition is the check is done on results that were not flagged as rounded by the fpu. In other words the value should be exact (unless overclocked error) and comparable to a known exact value.

If the "roundoff occurred" flag isnt getting set from this bug, the algorithms may be checking results that were indeed rounded with perfect values to detect instability (which does not necessarily indicate instability).

mds

Hm, there's a possibility you are right. Let me see whether I can find it in mprime's source.

However, none of this changes the fact that at least for me it was very hard to get a mostly-stable overclock mprime-stable, but all it took to do so was take the clocks down and CPU voltage up. That makes it unlikely that the original problem was caused by an arithmetic bug in the CPU.

[uOpt]

Can somebody post the exact error message from an mprime failing with "not exact in round" or whatever it is saying?

I don't have an unstable machine handy

[AnjinSan1966]

Can somebody post the exact error message from an mprime failing with "not exact in round" or whatever it is saying?

I don't have an unstable machine handy

It says:
FATAL ERROR:Rounding was 0.49609375, expected less than 0.4
Hardware failure detected,consult stress.txt file.