Solution : reason for failing conroes at prime

Printable View

08-28-2006, 09:05 AM
realsmasher

Solution : reason for failing conroes at prime

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

Quote:

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 :)
08-28-2006, 09:09 AM
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?
08-28-2006, 09:16 AM
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.
08-28-2006, 09:18 AM
Reite

Damn, anyway for them to fix that with bios change or do they need to fix the chip itself?
08-28-2006, 09:22 AM
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.
08-28-2006, 09:37 AM
LexDiamonds

Quote:

Originally Posted by Reite

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.
08-28-2006, 09:53 AM
lopri

Solution for Prime failing Conroes?

Lower the OC by 200MHz. :D

But on more serious note, I tend to notice some inconsistency with 4MB L2 chips.
08-28-2006, 10:12 AM
toledo

Quote:

Originally Posted by 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.

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 . :(
08-28-2006, 10:19 AM
Btrice

Quote:

Originally Posted by toledo

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).
08-28-2006, 10:22 AM
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.
08-28-2006, 10:35 AM
Plaicd

Seems to me if it was a prime failure because of this cpu bug then it would fail at stock speed too.
08-28-2006, 10:40 AM
Btrice

Quote:

Originally Posted by Plaicd

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?
08-28-2006, 10:47 AM
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.
08-28-2006, 11:24 AM
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.
08-28-2006, 11:47 AM
toledo

Quote:

Originally Posted by Btrice

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 .
08-28-2006, 11:53 AM
kiwi

Don't say you are overclocking and making serious computations then :D
08-28-2006, 11:56 AM
sombrio

Quote:

Originally Posted by Plaicd

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

Exactly. :)
08-29-2006, 12:42 AM
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.
08-29-2006, 02:03 AM
lawrywild

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

All you've done is listed what Intel have said is a bug..
08-29-2006, 05:01 AM
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.
08-29-2006, 05:39 AM
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… :)
08-29-2006, 06:51 AM
mds47

Quote:

Originally Posted by 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.

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
08-29-2006, 10:11 AM
uOpt

Quote:

Originally Posted by mds47

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.
08-29-2006, 10:13 AM
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 :)
08-29-2006, 10:59 AM
AnjinSan1966

Quote:

Originally Posted by 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 :)

It says:
FATAL ERROR:Rounding was 0.49609375, expected less than 0.4
Hardware failure detected,consult stress.txt file.
08-29-2006, 11:37 AM
uOpt

The code coming up with this doesn't use any of the flags or exceptions. It just checks what the maximum error from an expected result was doing nothing but normal FP instructions.

I also have to say that the tolerance chosen seems very high. I wonder what happens if I tighten it up by an order of magnitude...

So no, this CPU bug cannot have to do with mprime.

I don't think SuperPi has source code available, that might be worth a look, too.
08-29-2006, 11:52 AM
typo_pl

Looking at CPU errata for previous Intel CPUs shows that the same erratum exists for the Core Duo (not Conroe == Core 2 Duo) and the PentiumIII CPUs, but not for the P4.

Care to guess where C2D comes from?
08-29-2006, 12:53 PM
Ruhnie

Quote:

Originally Posted by AnjinSan1966

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

That is the exact error I get whenever I run Prime95 or Orthos blend, and I get it anywhere from 10 seconds to 4 mins in. I get this even at stock settings on my E6400, so does that mean I have this bug? What does this mean for someone who primarily wants to OC and use their rig for gaming? How exactly do I know if I'm stable?
08-29-2006, 02:24 PM
mds47

I think uOpt is right on this one. This bug has no effect on prime torture testing.

The errors you're seeing are ordinary instability errors. Either your voltage is too low, your heat is too high, or the chip simply can't handle the hertz.
08-29-2006, 02:34 PM
Gautam

What might be hard for people to grasp is that there is a very large gap between prime stable speeds and superpi/3D stable speeds. 1M pi -> dual prime has been around 300MHz for me on two CPU's. If 3DMark06 and PCMark05 can be completed at a certain speed, then chances are that Prime can be within 50MHz or so.

However, I was never personally able to get A64's prime stable. I ignored it altogher, but have used it for Intel systems.
08-29-2006, 02:50 PM
Vric

Prime fail for me after 2 hours. Dual prime, one of the 2 simply crash.
I tried rising Voltage (I'm at stock voltage) with no better result.

I'm only at 320x9 on my E6600 (making it at 2.9Ghz) CPU can go much higher, but the OCZ Plat memory simply hate any divider beside 2:3 or 4:5.

I'm sure it's the memory that caused this problem. While testing them with memtest, they would fail randomly at any speed (even under stock speed).

Beside the Prime crash after 2 hours, I have no problem at all. Running all bench and games. Computer run 14 hours a day without problem.
08-29-2006, 04:13 PM
Btrice

Quote:

Originally Posted by toledo

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 .

Sorry couldn't get it all installed till tonight. Results exactly the same as my work machine down to 1x10^-9 (probably even more but that is as far as my data printed out for that run).
08-30-2006, 02:07 AM
lawrywild

I think it's all bull:banana::banana::banana::banana: tbh..

This is what happens when lots of people don't get the clocks they were expecting. People can't handle the fact that their cpus (or mobos) can't clock as high as some so feel the need to make excuses. I think people need to get over it tbh
08-30-2006, 02:22 AM
toledo

Quote:

Originally Posted by Btrice

Sorry couldn't get it all installed till tonight. Results exactly the same as my work machine down to 1x10^-9 (probably even more but that is as far as my data printed out for that run).

Thanks Btrice , good to know ;)

Quote:

Originally Posted by lawrywild

I think it's all bull:banana::banana::banana::banana: tbh..

This is what happens when lots of people don't get the clocks they were expecting. People can't handle the fact that their cpus (or mobos) can't clock as high as some so feel the need to make excuses. I think people need to get over it tbh

My concern was the CPU doing wrong calculations regardless of the overclock . I haven`t got my C2D yet :D
08-30-2006, 02:43 AM
lawrywild

Quote:

Originally Posted by toledo

Thanks Btrice , good to know ;)

My concern was the CPU doing wrong calculations regardless of the overclock . I haven`t got my C2D yet :D

well mine is fine at stock and 3.2 1.385v

It's only when I push it further that it fails.. i.e. it won't clock that far (or the mobo/chipset won't let it)
08-30-2006, 03:04 AM
kadinho

I think the prime bug it's different that cpu bug... My prime bug ocurrs at diferent times. 3s - 5s - 5 hours and at diferent speeds, 2.88 - 3 - 3.2 mhz .... Its just a feeling prime bug it's not the cpu bug...

cumps
08-30-2006, 04:16 AM
pcdoc1

Quote:

Originally Posted by kadinho

I think the prime bug...

The Prime Bug? Who started this BS... Years after development, disappointed users are now blaming the app...:D:D
08-30-2006, 05:54 AM
herderien

Quote:

Originally Posted by 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… :)

well then tell me why am i priming stable with bios 0502 and not 0507 with exactly same settings? this cannot be related to OC stability
08-30-2006, 06:12 AM
pcdoc1

Quote:

Originally Posted by herderien

well then tell me why am i priming stable with bios 0502 and not 0507 with exactly same settings? this cannot be related to OC stability

That just further makes the point! It maybe a bios or chipset issue, but not a "Prime Bug" as being stated...
08-30-2006, 06:14 AM
astaris

Quote:

Originally Posted by herderien

well then tell me why am i priming stable with bios 0502 and not 0507 with exactly same settings? this cannot be related to OC stability

Different Bios use different hidden settings...

Quote:

Originally Posted by kadinho

I think the prime bug it's different that cpu bug... My prime bug ocurrs at diferent times. 3s - 5s - 5 hours and at diferent speeds, 2.88 - 3 - 3.2 mhz .... Its just a feeling prime bug it's not the cpu bug...

That's a good one, Prime Bug...
Uhm i think here the bugged ones are the users that fail to admit their system is not 100% stable.
08-30-2006, 06:22 AM
herderien

Under certain rare conditions, this bit may not be set when this rounding occurs.

memory settings + whatever hidden setting + demanding software ?

so my point is still valid

ps : i'm not saying it's a prime bug i'm just on the first statement that it is a cpu bug
08-30-2006, 06:50 AM
Lestat

logic would dictate that even at stock even at 100mhz a conroe would cause prime failures if there is a bug in the cpu.
but the fact is thats not true. not for 99% of the people.

so that throws the bug theory out the window does it not ?

if its overclocking thats causing the failures. then that right there, without a doubt is the answer.

why debate it. if it runs fine at stock and yet fails when you overclock... what does that say ? to deny it is just silly.

UNLESS the bug is DIRECLTY related to higher clockrates of the core 2 duo chip. which i havent seen anything yet to denote that the higher clock rate causes the bug to surface
08-30-2006, 07:03 AM
crspyjohn

I am having this problem at stock speeds as well :( Should i return my chip?
08-30-2006, 07:06 AM
Pyr0

check your memory and psu first
08-30-2006, 07:19 AM
crspyjohn

ah, it can memory or psu. I'll check those out. thansk!
08-30-2006, 07:41 AM
Ruhnie

Yeah, in my case, I think the memory is the problem, using the OCZ Plat 6400. Anytime I run a divider other than 4:3 I get the errors, even with the CPU/mobo at stock speeds and volts. :(
08-30-2006, 08:49 AM
Lestat

4:3 equals what ? whats your ram running at ?
08-30-2006, 09:43 AM
Fred_Pohl

There is no 'C2D/965 Prime bug'. This is an 'overclocked too high bug', plain and simple.
08-30-2006, 09:53 AM
Btrice

Quote:

Originally Posted by Fred_Pohl

There is no 'C2D/965 Prime bug'. This is an 'overclocked too high bug', plain and simple.

Quote:

Originally Posted by crspyjohn

I am having this problem at stock speeds as well :(

:wave:
08-30-2006, 10:16 AM
Fred_Pohl

No offense meant to crspyjohn but he's had an amazingingly long list of problems with his new build.

If there was any relation between this errata and Prime rounding errors, it wouldn't be isolated to a handful of C2Ds, with most of them OC'd by ~50%. It would affect every C2D.

http://img242.imageshack.us/img242/6...hrlgfftjx1.jpg
08-30-2006, 10:20 AM
M.Beier

Quote:

Originally Posted by 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.

I belive that was due the IMC being weak.. - And timmings with BH5 being to aggressive, not 1.5-2-2-5, but some of the others..
08-31-2006, 03:28 AM
Entsafter

My E6600 is strange under dual-prime load...
2950 MHz with 1.27V dual-prime stable over hours...
3000 MHz with 1.3 - 1.6V unstable!

I lowered the multi from 9 to 7 and started testing with FSb 400+ ... same problem!
Mobo: P5B Deluxe Wifi
I tryd different settings:
Vcore: 1.3-1.65V
FSB Termination: Auto-1.45V
NB: Auto- 1.65V
SB: Auto - 1.7V
I tryd also every Multi but the problem still exists.. I can't run prime over 2950 MHz... but I can run Super-Pi till 3510 MHz with 1.39V.. and above 3600Mhz with more Voltage... really strange...
I use Corsair 8000UL and 1:1 divider, I removed also one stick ... but the situation is still the same...
I don't know where's the problem! Probably it's only one setting in bios!

btw: speedstep and other voltage reducing and multi reducing features are off...
08-31-2006, 05:08 AM
Vric

Dual prime fail after 2 hours on my E6600 at 2.9Ghz, but Orthos pass for over 8 hours.
08-31-2006, 06:18 AM
Artmic

Interesting, i OC'ed my x6800 to 3.46Ghz and it failed Orthos after only 3min testing CPU+Memory.

I got a TR SI-128 heatsink and panaflo M1 fan, so i figure my fan blows(just not air) so i'm replacing the fan with the panaflo H1 fan right now, i figure 103.8 cfm should do the trick and cool it down even more. (maybe)

I can see how the people that purchased the e6600 can love their processors, for me the X6800 leaves a bad taste behind, you'd figure after spending so much money and having an open Multiplier, you'd be able to do 3.46Ghz with even the stock cooler, never mind an aftermarket SI128 with a fan that sounds like a tractor pushing so much air onto it.

Well my retail X6800 is now running 3.2Ghz, stably. I will try to attempt the 3.46 with the new fan.

There is a reason Intel lowered the fastest Conroe from 3.2Ghz to 2.93Ghz, ... and it has nothing to do with marketing or squeezing more money out of joe-six-pack..... i figure there is only so far they can take these C2D on air, before they start roasting pigs on an open fire.
08-31-2006, 08:07 AM
chrisf6969

Quote:

Originally Posted by Artmic

There is a reason Intel lowered the fastest Conroe from 3.2Ghz to 2.93Ghz, ... and it has nothing to do with marketing or squeezing more money out of joe-six-pack..... i figure there is only so far they can take these C2D on air, before they start roasting pigs on an open fire.

Thats what I'm thinking. Before I thought they did it just so they could gradually roll out new products instead of blowing their whole wad at the launch. But I'm having problems right around 3Ghz too.
08-31-2006, 08:11 AM
Entsafter

Hmm I've tested my second E6600... same problem.. but 100 Mhz higher... STRANGE!!!
I sell all Core2Duo stuff and buy an old D950... it's more stable than this new superduperfast CPUs... I can run Super-Pi 600 MHz higher than Dual-Prime.. that sucks hard... the point is that I can only use this cpus @ 2.95 GHz for daily use... with 1.25V or less... raising vcore doesn't help to improve the stability... Maybe the board ist crap... expensive P5B Deluxe Wifi! Bios 0507..
08-31-2006, 11:58 PM
realsmasher

EVERYONE who uses conroe overclocked, leave this thread IMMIDIATLY.

this here discussed problem has NOTHING to do with OC, so go away. people like you bring trolls here that say : "hoho not a bug, it's you OC".

i repeat it again for all those "wise guys" : this is not related to OC or any stability.

it appaers at ANY clock with ANY voltage but only on SPECIAL Chipset/bios/ram settings, but there is actually no way to find out why.

so this flag-bug COULD be a good reason.
09-01-2006, 01:42 AM
astaris

Quote:

Originally Posted by realsmasher

EVERYONE who uses conroe overclocked, leave this thread IMMIDIATLY.

this here discussed problem has NOTHING to do with OC, so go away. people like you bring trolls here that say : "hoho not a bug, it's you OC".

i repeat it again for all those "wise guys" : this is not related to OC or any stability.

it appaers at ANY clock with ANY voltage but only on SPECIAL Chipset/bios/ram settings, but there is actually no way to find out why.

so this flag-bug COULD be a good reason.

This flag bug has nothing to do with the reason Prime fails, if the two things where connected then all people here (overclocked or not) should experience Prime rounding error but it's not this way...
If Prime fails then your system is unstable (due to overclocking, bad memory, poor bios, poor bios settings...)
You started a thread titled "Solution : reason for failing conroes at prime", then before saying "EVERYONE who uses conroe overclocked, leave this thread IMMIDIATLY", then change the title thread to something else i.e. "guys look, Conroes has a bug...", so the one trolling here is only the thread starter, of course due to the title of your thread, due to the fact that we are on xtremesystems and not on underclockedsystems, there are lot of people that overclocks that post in this thread...
And about your statement "it appaers at ANY clock with ANY voltage but only on SPECIAL Chipset/bios/ram settings, but there is actually no way to find out why", what happens, that prime fails? -> speak for yourself / your system, that conroe has a bug? -> who cares?
09-01-2006, 06:27 AM
uOpt

I ran dual mprime for like a week after I stabilized my E6600. At 3600 MHz...

This CPU bug has no impact on mprime. I read mprime's source code. It's not using that flag that might be incorrectly not raised by this CPU bug.
09-01-2006, 07:46 AM
mds47

Quote:

Originally Posted by uOpt

I ran dual mprime for like a week after I stabilized my E6600. At 3600 MHz...

This CPU bug has no impact on mprime. I read mprime's source code. It's not using that flag that might be incorrectly not raised by this CPU bug.

QFT

The flag has absolutely no effect in prime95. It's just a status flag you can optionally check on the FPU, and prime95 does not check it.

If you're getting errors in prime95 at stock, it's either a different cpu bug (not listed in the errata) or a problem somewhere else in your system.

mds
09-01-2006, 07:57 AM
[XC] hipno650

why use prime at all? why not get the ultimate stabilty test and help fight cancer and aids!!!!!!! come over to the dc valut and go to the WCG section and we will set you up from there!!!!!:) if your conroe is unstable you will know it by running WCG!!!!!!

Uncle Sam wants you to fold WCG!!!!!!!!
09-01-2006, 10:42 PM
realsmasher

so you guys say it cannot be a bug as not everyone gets this.

but what about that : the bug only appears together with other stuff ?

as you see, i'm not the only one having this "problems" and if prime would recognize an error SO early, don't you think the computer would crash at other stuff ?

how can it make sense, that only ONE program crashes due to instability ?

and the reason why i write this here : there are several threads asking for a reason/solution for this BUG.

yes in my opinion it is a bug, cause my system is even stable with 0.2V lower with all other programs(and prime small ftt), but not even at stock or higher vcore at large ftt. there is no other logical reason then a bug.

plus : is comes on different rams,, ram settings, different boards und different cpus(not only conroes, also allendales).
09-02-2006, 02:19 AM
Shintai

Quote:

Originally Posted by realsmasher

so you guys say it cannot be a bug as not everyone gets this.

but what about that : the bug only appears together with other stuff ?

as you see, i'm not the only one having this "problems" and if prime would recognize an error SO early, don't you think the computer would crash at other stuff ?

how can it make sense, that only ONE program crashes due to instability ?

and the reason why i write this here : there are several threads asking for a reason/solution for this BUG.

yes in my opinion it is a bug, cause my system is even stable with 0.2V lower with all other programs(and prime small ftt), but not even at stock or higher vcore at large ftt. there is no other logical reason then a bug.

plus : is comes on different rams,, ram settings, different boards und different cpus(not only conroes, also allendales).

BIOS update will fix with microcode corrections. And the reason SP2004 fails is roughly due to it being coded wrongly. But ofcause it should still work.
09-05-2006, 05:00 AM
uOpt

Quote:

Originally Posted by realsmasher

so you guys say it cannot be a bug as not everyone gets this.

Nobody said that. All we say is that Mprime does not use the CPU feature that has this particular bug.

Quote:

Originally Posted by realsmasher

but what about that : the bug only appears together with other stuff ?

as you see, i'm not the only one having this "problems" and if prime would recognize an error SO early, don't you think the computer would crash at other stuff ?

how can it make sense, that only ONE program crashes due to instability ?

Two reasons:

1) Mprime ist just very intense heat-wise

2) Mprime in self-test mode does a test (duh) of its results and detects when things are wrong. Most other programs continue to compute with previous wrong results without noticing.

Quote:

Originally Posted by realsmasher

and the reason why i write this here : there are several threads asking for a reason/solution for this BUG.

yes in my opinion it is a bug, cause my system is even stable with 0.2V lower with all other programs(and prime small ftt), but not even at stock or higher vcore at large ftt. there is no other logical reason then a bug.

plus : is comes on different rams,, ram settings, different boards und different cpus(not only conroes, also allendales).

This CPU bug CANNOT have to do with the mprime instability when overclocking core2. Mprime does not use that flag that is sometimes not raised when it should.

You also seem to forget that mprime gets stable if you take the clocks back enough (or raise voltage when appropriate).

Face it: Conroe just has more headroom for usable but not entirely stable overclock. But to be entirely mprime stable you have to take those clocks back to stables levels simple.

I also remind people that the math errors disappear when you take back the clocks.
09-05-2006, 05:19 AM
uOpt

Quote:

Originally Posted by realsmasher

so you guys say it cannot be a bug as not everyone gets this.

Nobody said that. All we say is that Mprime does not use the CPU feature that has this particular bug.

Quote:

Originally Posted by realsmasher

but what about that : the bug only appears together with other stuff ?

as you see, i'm not the only one having this "problems" and if prime would recognize an error SO early, don't you think the computer would crash at other stuff ?

how can it make sense, that only ONE program crashes due to instability ?

Two reasons:

1) Mprime ist just very intense heat-wise

2) Mprime in self-test mode does a test (duh) of its results and detects when things are wrong. Most other programs continue to compute with previous wrong results without noticing.

Quote:

Originally Posted by realsmasher

and the reason why i write this here : there are several threads asking for a reason/solution for this BUG.

yes in my opinion it is a bug, cause my system is even stable with 0.2V lower with all other programs(and prime small ftt), but not even at stock or higher vcore at large ftt. there is no other logical reason then a bug.

plus : is comes on different rams,, ram settings, different boards und different cpus(not only conroes, also allendales).

This CPU bug CANNOT have to do with the mprime instability when overclocking core2. Mprime does not use that flag that is sometimes not raised when it should.

You also seem to forget that mprime gets stable if you take the clocks back enough (or raise voltage when appropriate).

Face it: Conroe just has more headroom for usable but not entirely stable overclock. But to be entirely mprime stable you have to take those clocks back to stables levels simple.

I also remind people that the math errors disappear when you take back the clocks.

All times are GMT -8. The time now is 12:13 AM.

XtremeSystems