News Prime95: Intel erkennt Stabilitätsproblem bei Skylake-CPUs an

meckswell schrieb:
Vllt is die Kiste des "Entdeckers" auch nur nicht stabil, oder der Speichercontroller defekt, oder der Ramtakt zu hoch und nicht stabil.

768k wird üblicherweise genommen um den IMC zu testen.

Ich gebe auf die Meldung, dass Skylake ein Problem hat, überhaupt nichts.
Nene, das tritt auch mit Standard Takt bzw. Default Einstellung auf und auch von mir damals mit ASRock TW publiziert worden.
Ergänzung ()

aurum schrieb:
Das Problem ist seit Mitte Oktober bekannt. Wobei mir anfänglich niemand geglaubt hat.
Doch nach eigenen Tests mit 768K und hatte interne Kontakt mit vielem hin+her :-/
 
TigersClaw schrieb:
Bei mir steht Microcode Update Revision: 1Eh

Ist das nun neuer oder älter?
Tendenziell würde auch ich sagen deine Version ist (deutlich?) älter. Aber sicher bin ich mir da nicht.

Welche BIOS Version setzt du denn überhaupt ein!?

Für das GL752VW gibt es bei ASUS ein neues BIOS (Version 210) vom 05. Januar: klick mich
Vielleicht ist hier ein Microcode Update drinnen. Könnte man mal ausprobieren!? :)
 
Also fassen wir mal zusammen:

Der Fehler tritt nicht mit allen Skylake Prozessoren auf, sondern nur mit den K
Der Fehler tritt nicht mit jeder Software auf, sondern nur mit Prime (Stand heute)
Der Fehler tritt nicht bei jeder x-beliebigen Prime Einstellung auf, sondern nur bei einer einzigen.

Kein Prozessor ist fehlerfrei, Intel gibt das offen zu und macht daraus kein Geheimnis. Es ist
auch schlichtweg nicht möglich, jeden Prozessor mit jedem Programm auf dem Planeten mit
jeder Einstellung zu testen. Also worüber reden wir eigentlich? Ich kann im Moment kein
Problem erkennen, das jeden Skylake User betrifft. Der hier beschriebene Fehler tritt als nur
dann auf, wenn man eine K CPU hat, bewusst Prime startet, genau so einstellt und einen
halben Tag auf den Absturz wartet. Was genau beweist das? Genau eine Sache nur:

Dass dieses Szenario mit diesen beiden Prozessoren aktuell nicht machbar ist. Mehr nicht.
 
@borizb
So pauschal kannst du das nicht sagen...

- JA, es betrifft nicht alle Skylake CPUs (BISHER nur 4 Kerne + Hyperthreading bei hoher Last)
- NEIN, das ist schlichtweg falsch, weil komplexe mathematische Berechnungen nicht nur mit Prime durchgeführt werden.
- JEIN, was Prime betrifft mag das stimmen, aber AVX ist jetzt nicht unbedingt etwas, was nur Prime nutzt. Potenziell sind also weit mehr Anwendungen betroffen (vielleicht sogar JEDE Anwendung die AVX nutzt)
 
Steps to freeze your Skylake System:

Dies verdeutlicht, dass das Problem nur bei bestimmten Bedingungen auftritt.

... und bezeichnete den oben beschriebenen Weg zur Reproduktion des Fehlers als ungeeignet. Die richtigen Einstellungen zeigt er in Form eines Screenshots auf.

Mit der Version 27.9 von Prime95 trete der Fehler zügiger als mit Version 28.7 auf. Es könne aber dennoch über 12 Stunden dauern, bis sich der Fehler in Form „eines aussteigenden Werkers“ bemerkbar mache. „Mitunter muss man auch einige Male neustarten“, heißt es weiter. Außerdem habe er den Fehler nur mit den Prozessoren Core i7-6700K und Core i7-6700 reproduzieren können.

Nachtrag: Der Entdecker hat seine Anleitung nochmals präzisiert: ...

An der Wortwahl und den vielen Variablen erscheint es mir so, dass man diesen "Fehler" mit dem allergrößten verfügbaren Elektronen-Mikroskop gesucht und tatsächlich gefunden hat.

Tritt der "Fehler" überhaupt in Alltagssituationen auf?

Für mich klingt das in etwa so: Ich habe einen Fön, der unter bestimmten Bedingungen überhitzt. Dazu muss die Raumtemp. unnormale 25°C betragen und der Fön muss min. 3 Std am Stück auf höchster Stufe laufen. Außerdem muss man den Test ggf. einige Male am Stück wiederholen, um eine Überhitzung zu erreichen. Nachtrag: bei blonden Haaren muss man den Fön im 85° Winkel zum Kopf halten, um die Überhitzung zu erreichen.
 
J Z schrieb:
Ergänzung ()

Doch nach eigenen Tests mit 768K und hatte interne Kontakt mit vielem hin+her :-/

Das stimmt nicht. Die ersten > 2 Wochen habe ich mit einer Weißen Wand gesprochen. Der erste der es nach unzähligen PNs nachvollziehen konnte war ralle_h.


Hab gerade schon mal das neue BIOS für das OC Formula bekommen und stelle es gleich online. Ich hoffe, dass das mit dem neuen MC funktioniert.

Vcore wurde angehoben, Cache von 4,1 GHZ auf 4 GHZ abgesenkt. Die Bios VID ist gestiegen. Der Test läuft gerade.

Tritt der "Fehler" überhaupt in Alltagssituationen auf?

Ist bisher unklar.
 
Das sind einfach unsinnige Vergleiche, die viele hier ziehen. Prime findet den Fehler ja früher oder später, weil es Mersenne-Zahlen über FFT-Algorithmen auf Primalität überprüft. Würde man die exakte Konstellation dieses Fehlers kennen, könnte man ihn auch direkt reproduzieren. Pauschal zu behaupten, dass der Fehler in der "Praxis" nicht auftreten wird, ist einfach Unsinn. Selbstverständlich kann der Fehler im Alltag bei vielen Anwendungfeldern ebenfalls auftreten. Zugegeben: für Zocker-Kiddys, die ihren Computer auf eine Spielemaschine reduzieren und mit wissenschaftlicher/programmiertechnischer Arbeit nichts am Hut haben, wird der Bug in der Tat keine Relevanz haben ;).
 
aurum schrieb:
Das stimmt nicht. Die ersten > 2 Wochen habe ich mit einer Weißen Wand gesprochen. Der erste der es nach unzähligen PNs nachvollziehen konnte war ralle_h.
War ja auch ein blöder Bug, nach ralle_h hatte ich Kontakt mit ASRock NL/TW, Nick usw... Gestern du noch mit Peter F. ;-) Auch wenn ich nicht immer schreibe, bin ich doch im Hintergrund mit dabei.
 
DerBaya schrieb:
Ich verstehe die Aufregung nicht. Solang im Alltag alles in Ordnung ist, muss ich doch nicht versuchen mit irgendeiner Software Fehler "herbeizuführen" ??? :confused_alt:

Wenn ich aber einen PC beispielsweise zum Video Rendern verwende, und dann nach mehreren Stunden Renderzeit ein Fehler auftritt, kann es eben passieren, dass im Video hinterher ein grünes Bild aufblitzt oder ähnliche Scherze.
Deshalb lasse ich solche PCs grundsätzlich erst mal durch mehrere Pässe memtest und danach 24 Stunden Prime laufen (auch ohne OC), weil hier solche Fehler eben provoziert werden.
Wenn ich mit so einem PC Office Arbeiten mache, dann passiert wahrscheinlich nie etwas. Selbst beim Videoschnitt wird wahrscheinlich nichts passieren. Aber wenn Prime fehlerfrei 24 Stunden läuft, dann ist die Wahrscheinlichkeit eben viel höher.

nex86 schrieb:
Prime Fehler machen sich im praktischen Alltag nicht wirklich bemerkbar.
Hatte meinen alten i5-2500k damals für mehrere Monate übertaktet gehabt und trotz Prime Fehler im Alltag nie Probleme gehabt, weder Bluescreens noch sonstwas.
Würde mir also keine Gedanken machen.
Wenn du aber z.B. stundenlang Video renderst und hinterher sind Störungen im Bild (und sowas kann eben passieren) dann ist das u.U. extrem ärgerlich, kostet viel Arbeitszeit und kann Leuten auch professionell Probleme machen. Nicht jeder Freelancer Editor/Cutter hat unbedingt eine Xeon Workstation zum Arbeiten, viele arbeiten da mit Consumer-CPUs.
 
Zuletzt bearbeitet von einem Moderator:
highks schrieb:
...Deshalb lasse ich solche PCs grundsätzlich erst mal durch mehrere Pässe memtest und danach 24 Stunden Prime laufen (auch ohne OC), weil hier solche Fehler eben provoziert werden....

Das bringt Dir rein gar nichts. Solche Tests machen die Hersteller rauf und runter. Und wie man hier an der Diskussion sieht, ist das einer dieser sehr seltenen, schwer bis nicht replizierbaren Fehler. Die sind in Softwareprogrammen schon ein Alptraum...
 
@Mr.Seymour Buds
Exakt, ich hatte einen Core i7 6700k mit fehlerhaften Speichercontroller, er zeigte Freezes nur im Regelbetrieb aber war mit 24h mPrime und Memtest86 völlig stabil.

Nur Memtest86+ hat Fehler gezeigt.
 
Zuletzt bearbeitet:
Bei meinem Haswell ist es genau so, Prime läuft stabil, aber Anwendungen und Spiele stürzen ab, selbst, wenn er nur leicht übertaktet wird.
 
Zuletzt bearbeitet von einem Moderator:
Sind die Laptop Xeon Pozessoren (Xeon E3-1535M) auch davon betroffen ?
 
Zuletzt bearbeitet:
borizb schrieb:
Der Fehler tritt nicht mit allen Skylake Prozessoren auf, sondern nur mit den K
Er tritt bei potenziell allen auf. Das schließt vorallem auch Server CPU's ein (e.g. E5-26xx v5)
borizb schrieb:
Der Fehler tritt nicht mit jeder Software auf, sondern nur mit Prime (Stand heute)
Da wäre ich mir beim Einsatz von AVX nicht sicher. Gerade im Umfeld der Virtualisierung wird AVX sehr verbreitet eingesetzt. Ohne AVX starten einige VAs nur im lite-modus (e.g. stark eingeschränkter network throughput) oder gar nicht.
 
borizb schrieb:
Also fassen wir mal zusammen...
Also wenn man mal zusammenfassen will, solltest du das gelesene auf verstehen.
Das Problem soll bei allen 4 Core + SMT CPUs auftreten. Insofern muss man deiner Ausführung wenig Bedeutung beimessen.
 
Für mich eher meckern auf sehr hohem Niveau :evillol:
In der normalen Praxis sicher nicht ansatzweise zu merken.

Dazu noch das Intel schnell ein BIOS Fix angekündigt hat:cool_alt:
 
eremit007 schrieb:
Da war doch erst kürzlich dieser Artikel: Einblicke in die Komplexität eines x86-Prozessordesigns
"Auch nach vielen Jahren Zeit und Millionen Kosten wird eine CPU niemals fehlerfrei sein."

Und dieser ex-AMD Mitarbeiter wurde auch schon zurechtgewiesen.

. Maier left the company many years ago. Tools for automated design have extensively be used for Bobcat (it's a synthesizable design) and for 10h, 11h, BD, the GPUs and so on. But all that in different amounts. The BD ISSCC papers mention explicit optimization of critical paths if there were some. But this is not the same as a fully synthesized design (like Bobcat), where AMD engineers stated 20% lower performance and 20% more area. Xbit labs gets everything wrong somehow.

Further background info:
http://forums.anandtech.com/showpost...3&postcount=82
http://forums.anandtech.com/showpost...2&postcount=91

http://www.xtremesystems.org/forums...Sandy-Bridge&p=4977145&viewfull=1#post4977145
 
stoneeh schrieb:
Kann mich noch an meinen Athlon XP 3200+ erinnern, der mit dem Boxed Lüfter in keiner Anwendung stabil lief. Brauchte einen massiven Tower-Lüfter, um diese CPU unübertaktet mal stabil zum laufen zu bringen. DAS nenn ich bedenklich.
Komisch, der damalige PC von meiner Mutter lief stabil (3200+ Thoroughbred-B oder was das war), auch wenn die Temperaturen hoch (aber nicht gefährlich hoch) waren (OEM-Schrottkühler). Und mein 2500+@"3400+" (Barton) lief mit vernünftigen Temperaturen mit einem Thermalright SK6 (oder wars schon der SLK800?). Und das war auch kein Tower!
Soweit ich es in Erinerung habe, kamen die Tower auch erst zu A64-Zeiten, zumal die Towerkühler aufgrund der hohen mechanischen Belastung mit dem dem nacktem Die kurzen Prozess machen würden, die Sockelbefestigung (nicht viel besser als beim 486er) war damals auch weitaus wackeliger als später.

rg88 schrieb:
@stoneeh: Das war aber nie ein "Fehler" der Athlon XP CPUs, sondern der Grund war dann ein mieses Mainboard oder der darauf verbaute Chipsatz. (Ich trau mich wetten es war ein VIA oder eventuell noch SiS).
Der KT266A (war allerdings vor dem 3200+) lief jedenfalls vernünftig (zumindest bei Epox) und der NForce2 ebenfalls. Der KT333 und sowie KT400 soll nicht mies gewesen sein, nur konnten diese dem NForce2 lange nicht das Wasser reichen.
aber gut, etliche Chipsätze waren Banane (insbesonders VIA vor dem KT266A, was auch an der 686B-Southbridge lag), und darum ist der eigentlich sehr stabile Athlon XP in Verruf gekommen.

Allerdings hatte ich zuerst auch Freezes gehabt beim 2500+ auf dem NForce2-Board (Epox 8RDA3+), dafür lief es nach der Reparatur (wurde vom Händler eingeschickt) bombig und bis vor anderthalb Jahren noch bei meinem Vater, dann kam der Tausch auf was Aktuelleres (und Win7 statt XP). Wurde aber auch Zeit, beim Ausbau hatte ich gesehen, dass etliche Elkos dicke Backen hatten (beim Spannungswandler für CPU allerdings nicht, da waren noch Sanyos verbaut).
 
Zuletzt bearbeitet:
Zurück
Oben