Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsPrime95: Intel erkennt Stabilitätsproblem bei Skylake-CPUs an
Genau das wage ich stark zu bezweifeln. Hier wird ja nur über Prime demonstriert, wie sich der Fehler verhältnismäßig schnell reproduzieren lässt. Das heißt aber nicht, dass er in der alltäglichen Praxis nicht zufällig genau so auftreten kann. Prinzipiell umfasst die angegebene FFT mit 768*10^3 Summanden Multiplikation, komplexe Exponentialfunktion und die Summation. Wenn hier in einer bestimmten Konstellation Fehler auftreten, kann das auch im allgemeinen Betrieb der Fall sein. Insbesondere im wissenschaftlichen Bereich von Signal Processing und Co., wo die FFT nunmal unverzichtbar ist, dürfte der Skylake i7-6700 wohl aktuell nur mit Vorsicht zu genießen sein.
Ein Fehler, der nur unter extremster Beanspruchung, bei einem einzigen Programm (Derzeit), unter einer ganz bestimmten Revision jenes Programmes, und nur bei den richtigen Einstellungen auftritt.
Wenn er denn mal nach gewisser Zeit auftritt.
Da hatte irgendjemand entweder zu viel Zeit oder ein zu großes Geltungsbedürfnis.
Wie auch immer, die gesamten Skylake-Prozessoren die wir im Einsatz haben (und verbaut haben) tun ohne Probleme Ihren Dienst.
In meinen Augen wird hier die Mücke zum Elefanten aufgebauscht, aber Hauptsache mal wieder einen Aufhänger gefunden.
Die sind auch nicht automatisch sicher vor Fehlern, nur weil ein anderer Name draufsteht. Der TSX-Fehler von Haswell wurde ja höchstwahrscheinlich auch auf einem solchen System gefunden, weil die entsprechenden Befehle im Desktop-Segment eh nicht benutzt werden.
strex schrieb:
Viel schlimmer finde ich unentdeckte Bugs in VMX oder der IOMMU die einen Ausbruch ermöglichen könnten und so eine Sicherheitslücke darstellen kann die ziemlich gravierend sein kann.
Man kann aber nur dann überhaupt Code schreiben, wenn man annimmt, dass die CPU, von äußeren Einflüssen abgesehen, auch das tut, was im Code steht. Man kann robuste Programme schreiben, der eine Datenbank konsistent hält, wenn während einer Schreibeoperation mal der Strom ausfällt, man kann Ergebnisse validieren etc. etc., aber eben nur, wenn man annimmt, dass ein "a < b"-Vergleich auch nur dann wahr wird, wenn a wirklich kleiner als b ist, und die CPU nicht stehen bleibt, wenn man 3 mit 5 vergleicht. Das erfüllen CPUs normalerweise auch hinreichend gut - hier weiß man jetzt aber, dass es Fälle gibt, wo dies nicht der Fall ist, die vorher aber problemlos liefen.
Ich meine, wenn Intel den Fehler tatsächlich einfach per Microcode-/Firmware-Update beheben kann, den dokumentiert und dafür sorgt, dass das ganze bei Skylake-E gar nicht erst auftritt, ist ja auch alles wieder gut.
Es gibt Prozessoren, die so getestet werden, dass soe keine Fehler machen (Luft- und Raumfahrt, Militär und co.). Das sind Chips, die einen sehr kleinen Aufgabenbereich haben und extrem teuer sind. Zudem dauert ihre Entwicklung sehr lange. Das allers passt einfach nicht zu Heimanwender CPUs.
Geschickte Formulierung (und Platzierung) im letzten Satz - da gibts mal nen Intel-kritischen Artikel, und nach viel technischem Blabla bleibt dem Leser dann im Gedächtnis: "Skylake hat irgendein ultraselten auftretendes Problem, aber das ist ja inzwischen normal, hat letztens ein AMD-Heini auch so erzählt" ("die haben das ja auch ständig...")
Was hier manche denken? In den CPU wird jede Funktion doppelt und dreifach gecheckt. Davon abgsehen habe ich sowohl auf einem 6600T, als auch auf einen 6600k (jeweil non-oc) schon mehrere Stunden HPC Code laufen lassen und alles war im grünen Bereich. Zumindest meine Erfahrung ist bisher: Alles normal.
Es sind vermutlich auch nur Modelle mit HT betroffen respektive da lässt es sich einfach reproduzieren. Von dem her ist es nicht verwunderlich, dass es mit einem 6600k läuft
Zum 32. CCC hat David Kaplan, der fünf Jahre AMDs Bobcat und die Jaguar-Kerne mit designt hat und seit 2011 Hardware Security Architect von AMD ist, Einblicke in die Komplexität eines modernen x86-Prozessordesigns gegeben. Auch nach vielen Jahren Zeit und Millionen Kosten wird eine CPU niemals fehlerfrei sein.
wow - ein fehler den ich erst gezielt suchen muss und der nicht im allgemeinbetrieb auftritt? das ist nun wirklich die suche nach der nadel im heuhaufen....
Du kannst ja mal interessehalber mit einem Programm die Microcode Version bei deinem GL752VW auslesen. AIDA64 (Motherboard > CPUID) spuckt bei mir aus:
Microcode Update Revision: 49h
Der gleiche Wert steht bei mir auch im BIOS, wird also korrekt ausgelesen.
Ich würd mich jetzt mal soweit aus dem Fenster lehnen und sagen:
Wenn Intel einen Bug offen anspricht und nicht wie sonst (und auch andere Hersteller) üblich, auf veraltete BIOS-Versionen hinweisen und da dann das Microcode-Update einzuschmuggeln, dann ist der Bug eher als gravierend einzuschätzen.
Ein Bug der reproduzierbar (wenn auch aufwändig, aber das sind CPU-Bugs immer) in Prime auftritt, dann tritt dieser auch im normalen Umfeld hin und wieder auf. Wo genau der Bug verortet ist, geht ja bisher nicht aus dem Text hervor. Ich glaube nicht, das die Sache damit schon abgeschlossen und erledigt ist, sondern, dass diesbezüglich noch einiges ans Licht kommen wird. Ob ein simples Microcodeupdate ohne Einbußen in der Geschwindigkeit den Fehler fixt, bleibt abzuwarten.
Vllt hat damit auch die bescheidene Verfügbarkeit der 6000er Serie ihren Ursprung.
Ergänzung ()
quakegott schrieb:
wow - ein fehler den ich erst gezielt suchen muss und der nicht im allgemeinbetrieb auftritt? das ist nun wirklich die suche nach der nadel im heuhaufen....
Das hat nichts mit löblich zu tun, sondern mit Produkthaftung. Wenn ein offensichtlicher Fehler vorhanden ist, dann muss der Hersteller diesen umgehend beheben. Das ist keine nette Geste. Auf dem US-Markt kann sowas mehr als den Jahresumsatz an Strafe kosten, wenn dadurch Schäden (auch monetärer Art) verursacht werden.
Ergänzung ()
EvilsTwin schrieb:
Ist doch ein Fortschritt, frühere Generationen haben schon den Geist aufgegeben wenn man den Rechner in eine volle Badewanne gestellt hat.
OK bei Prime tritt der Fehler auf aber wo den noch und wie äußert er sich dann... Das ist doch ein theoretischer nonsens.
Dummer Verleich, und der Fehler ist sicherlich kein Nonsens.
EvilsTwin schrieb:
Bei den 486ern gab es auch mal einen Bug. der verursachte tatsächlich bei Excel Rechenfehler. Ab der xxxxxxten Nachkommatelle.
Unter bestimmten Bedingungen. Der Wind musste von süden wehen z. Bspl... Ein Hype, auch damals aber für 99,99usw. % der User total unerheblich...
Nein, das war ein Bug in der Pentium-Architektur. Und der war nicht unerheblich. Auf einem Arbeitsrechner werden und wurden vor allem damals viele Berechnung mit Excel ausgeführt. Hier gehts nicht darum, dass bei der Addition von 2 Zahlen ein Ergebnis herauskommt, sondern, dass ein korrektes Ergebnis herauskommt. Und bei größeren Berechnungen können sich solche Rechenfehler durchaus gravierend auswirken
Also wenn ich mir solche Mühe machen muss, einen nicht für praxisrelevante Anwendungen auftretenden Fehler zu erzwingen, geht das bei mir in die Kategorie "ferner liefen". Für sowas muss sich Intel wirklich nicht schämen.
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.. wenn ich nach ein paar Stunden PRIME mit gewissen, sehr spezifischen Settings, evtl einen Fehler bekomme, eher nicht.
@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)
CPU-Fehler findet man nur mit "praxisfernen" Tests, weil sie ja auch nur sporadisch auftreten. Genau dadurch sind sie ja so gravierend und unkalkulierbar. Das heißt ja nicht, dass die CPU direkt etwas falsch macht, sondern, dass evtl die Physik eben durch Leckströme in die Materie "reinpfuscht" und deshalb die Fehler eher "zufällig" auftreten.
Wenn sie aber wie hier, sogar in gewisser Hinsicht reproduzierbar sind, sind es gravierende Bugs die in zig anderen Alltagssituationen auch auftreten können.
Wenn sie aber wie hier, sogar in gewisser Hinsicht reproduzierbar sind, sind es gravierende Bugs die in zig anderen Alltagssituationen auch auftreten können.
Können, nicht müssen. Und da du genauso wenig darüber weißt wie wir, ist es einerlei ob man behauptet der Fehler sei irrelevant oder "gravierend", es bleiben haltlose Behauptungen.
