Archiv verlassen und diese Seite im Standarddesign anzeigen : News 14.10 / ECC Fehler
Hallo!
Nur eine Anmerkung zu dem "Todesurteil": Der Fehler tritt nur auf wenn Data Masking enabled wird. Data Masking an sich funktioniert Hardwaretechnisch aber nur bei x8 und x16 organisierten DIMMs. Die grossen DIMMs sind aber x4 organisiert :-). Selbst wenn dies ein Problem wäre könnte der Opteron Nutzer imer noch statt normalem ECC gleich Chip-Kill ECC verwenden.
P.S. Auch der Athlon 64 unterstützt ECC :-)
Endorphine
2003-10-15, 11:16:54
Genau. Es heisst explizit: 86 - DRAM Data Masking Feature Can Cause ECC Failures
Description
Under certain conditions, the memory controller fails to generate a DRAM read request when performing partial writes to an already allocated write combining buffer. Because the DRAM is not read for these subsequent write requests, the generated ECC bits are incorrect.
Potential Effect on System
Incorrect data can be read back from DRAM.
Suggested Workaround
BIOS should disable the data masking feature when ECC DIMMs are used by setting the DisDatMsk bit (Northbridge Configuration Register - MSR C001_001F, bit 36).
Fix Planned
Yes Der Text in der Newszusammenfassung liest sich wie ein Todesurteil für den Opteron :( Dabei handelt es sich nur um einen gewöhnlichen Bug. Ein Systemhersteller muss eben auf das DRAM mask-register Feature verzichten, mitnichten auf die korrekte Funktion der ECC-Prüfsummen.
Edit: Offenbar ist AMD noch nicht so wirklich im Server-Markt angekommen, welcher sich allerdings neue Dinge bekanntlich erst einmal eine Zeitlang aus der Ferne ansieht und dann erst mit einiger Verzögerung auf diese reagiert. Das finde ich sehr unfair geschrieben gegenüber AMD. Es hat auch nichts mit der Realität zu tun ;(
So befindet sich derzeit der SiS 755 für Athlon 64, Athlon 64 FX und Opteron in Massenproduktion und wird somit die Konkurenz zum nVidia nForce3 Pro150 und VIA K8T800 darstellen.
Konkurrenz
Abseites des eigentlichen Themas interessant an diesem Bericht sind die Ausführungen zu den Speicher- und Prozessorbesonderheiten beim Sockel 754, sprich beim "normalen" Athlon 64.
Abseits
In den letzten Monaten und Jahren hat in den Entwicklungsabteilungen vieler IT-Unternehmen eine neue Offenheit Einzug erhalten. Während Bugs des eigenen Produkts früher selbst dann noch verleugnet wurden, wenn sie durch unabhängige Stellen bereits öffentlich nachgewiesen waren, sind die Buglisten etwa der Prozessoren von Intel und AMD heute für jedermann frei zugänglich und nachzulesen.
Intel hat mit diesen Erratalisten angefangen und dafür nicht selten zu Unrecht Häme und Spott geerntet, als z.B. beim Pentium 4 am Tage der Vorstellung schon über 40 Bugs bekannt waren. Sinn dieser Fehlerlisten ist es, Bugs zu dokumentieren, um den BIOS-Programmierern und Compilerbauern die Möglichkeit zu geben, ein Workaround in ihr BIOS/Compiler einzubauen, welches das Problem geschickt umschifft. Wenn eine Befehlsfolge fehlerhaft arbeitet, darf ein Compiler die kritische Kombination eben nicht verwenden, sondern muß die Befehlsfolge mit einer alternativen Schreibweise realisieren. Damit wird der Kunde von diesem Bug nicht behelligt, obwohl er nach wie vor in der Hardware steckt.
Inzwischen pflegt auch AMD eine solche Liste über seine Prozessoren und Chipsätze. Ende vergangener Woche hat AMD die Errataliste (dort Revision Guide genannt) für den Athlon 64, den Athlon 64 FX und den Opteron veröffentlicht. So sind dort derzeit 37 Bugs dokumentiert, die entweder Athlon 64, Athlon 64 FX/Opteron oder beide betreffen. Interessant ist, daß in der aktuellen C0-Revision des Kerns bereits 14 Bugs der ursprünglichen Revision gefixt wurden. Für 6 Bugs ist kein Fix geplant und 3 Bugs sind in der Revision C0 neu dazu gekommen.
So findet sich in dem Dokument als Erratum #86 z.B. ein Fehler mit der Beschreibung "DRAM Data Masking Feature Can Cause ECC Failures". In der Tat hatten wir bei unseren Opteron- und Athlon 64 Reviews zwei Mal kritisiert, daß das Asus SK8N Mainboard mit aktiviertem ECC-Modus abstürzte oder unzuverlässig arbeitete. Zwar hatten wir uns schon damals gewundert, weshalb das Mainboard an diesem Fehler schuld sein kann, wenn der Speicher-Controller in der CPU steckt, aber da es von der Serverfront, wo der Opteron bereits seit April zuverlässig Dienst schiebt und ECC an der Tagesordnung ist, keine Klagen gab, schoben wir den Fehler auf das Mainboard. Die Errataliste dagegen entlastet Asus: der Fehler steckt wohl in der CPU und die Tatsache, daß es bisher keine Klagen von Serverbetreibern gab, liegt wohl einzig daran, daß der Bug erst mit der neuen Revision C0 "eingeführt" wurde. Ein Fix ist laut AMD geplant.
Interessant auch #58, welche einen Bug dokumentiert, der zu langen Latenzzeiten führen kann, wenn das System die CPU in den C1 (HALT) oder C2 (STOP) Modus schickt. AMD empfahl den BIOS-Programmierern deshalb, die Stromspar-Modi nicht zu nutzen (die Athlon/Athlon XP User kennen das ja, wenn auch aus anderen Gründen). Mit dem neuen C0-Stepping dagegen ist dieses Problem gefixt.
Alles in allem eine sehr interessante Lektüre für Technikfreaks. Der normale Anwender wird davon in der Regel - wie bei Intel auch - nichts mitbekommen, da die Workarounds normalerweise schon eingebaut sind, noch ehe der Ottonormal-User davon Wind bekommt. Der ECC-Fehler stellt hier eine Ausnahme dar. Mal sehen, was die nächsten Core-Revisionen so bringen...
Quelle planet3dnow mittwoch 8 oktober
teil der 3dcenter news
Doch für den Opteron-Prozessor müsste dieser Fehler eigentlich ein Todesurteil sein (daß AMD diesen Fehler mit dem nächsten Opteron-Stepping fixen wird, ändert auch nichts daran, daß alle derzeitig verkauften C0-Prozessoren kein ECC unter DDR333 beherrschen) - wozu kauft man sich ansonsten einen teuren Server-Prozessor, wenn nicht zur Ausnutzung dessen Möglichkeiten. Schon erstaunlich, daß dies bisher nicht so wahrgenommen wurde. Offenbar ist AMD noch nicht so wirklich im Server-Markt angekommen, welcher sich allerdings neue Dinge bekanntlich erst einmal eine Zeitlang aus der Ferne ansieht und dann erst mit einiger Verzögerung auf diese reagiert.
so verwunderlich ist das nun auch wieder nicht da es diesen Bug erst ab dem C0 Stepping gibt :)
Ja, diese Offenheit von Intel und AMD begrüße ich sehr. Nicht nur, dass dort Fehler eingestanden und korrigiert werden (in den meisten Fällen zumindest), sondern es kann sich auch jeder genaue Unterlagen zu den Cores runterladen, da könnten sich ATI und NV mal ein Beispiel daran nehmen. :)
Birdman
2003-10-15, 18:40:02
Original geschrieben von Gast
Interessant auch #58, welche einen Bug dokumentiert, der zu langen Latenzzeiten führen kann, wenn das System die CPU in den C1 (HALT) oder C2 (STOP) Modus schickt. AMD empfahl den BIOS-Programmierern deshalb, die Stromspar-Modi nicht zu nutzen (die Athlon/Athlon XP User kennen das ja, wenn auch aus anderen Gründen). Mit dem neuen C0-Stepping dagegen ist dieses Problem gefixt.
Bin ich nur paranoid oder wieso überschleicht mich das Gefühl dass hier wieder von den Moboherstellern global dieses Stromsparfeature ausgeschaltet wird, nur weil die zu faul sind einen Check aufgrund des Microcodes einzubauen?
Original geschrieben von Birdman
Bin ich nur paranoid oder wieso überschleicht mich das Gefühl dass hier wieder von den Moboherstellern global dieses Stromsparfeature ausgeschaltet wird, nur weil die zu faul sind einen Check aufgrund des Microcodes einzubauen? ne seit dem c0 step ist das ja gefixt worden, seitdem c0 ist ja der ecc fehler drin.
Birdman
2003-10-15, 19:16:13
Original geschrieben von Gast
ne seit dem c0 step ist das ja gefixt worden, seitdem c0 ist ja der ecc fehler drin.
gefixt ja, nur interessiert das die Mobohersteller?
Wenn die nur den Zustand 1 oder 0 setzen können, ohne irgendwelche Abfragen, dann bleibt es sicher auf 0 - weil sonst könnte es ja Probleme geben mit Usern welche eine <c0 CPU haben.
Leonidas
2003-10-16, 00:17:11
Fehler gefixt.
Zum Bug: Mmh. Es funtzt halt derzeit absolut nicht. Und im Servermarkt wird über sowas nicht verhandelt - da muß eine neue Plattform 3 Jahre fehlerfrei funktionieren, ehe man überhaupt dran denkt, den ersten Rechner damit auszurüsten.
Zum Todesurteil: Gerade weil AMD derzeit noch nicht so richtig im Servermarkt beachtet wird, bekommt man so eine neue Chance mit einem neuen Stepping. Doch wie groß wäre das Geschrei bei einem gleichen Fehler bei Intel?
Leonidas
2003-10-16, 00:19:39
Original geschrieben von Endorphine
Ein Systemhersteller muss eben auf das DRAM mask-register Feature verzichten, mitnichten auf die korrekte Funktion der ECC-Prüfsummen.
Genauer pls. Wer muß genau was machen?
Original geschrieben von Leonidas
Fehler gefixt.
Zum Bug: Mmh. Es funtzt halt derzeit absolut nicht. Und im Servermarkt wird über sowas nicht verhandelt - da muß eine neue Plattform 3 Jahre fehlerfrei funktionieren, ehe man überhaupt dran denkt, den ersten Rechner damit auszurüsten.
Zum Todesurteil: Gerade weil AMD derzeit noch nicht so richtig im Servermarkt beachtet wird, bekommt man so eine neue Chance mit einem neuen Stepping. Doch wie groß wäre das Geschrei bei einem gleichen Fehler bei Intel? Die steppings vor dem C0 waren bezüglich ecc ja in Ordnung! Wer weis genau ob opterons (habe nix finden können) überhaupt im C0 ausgeliefert werden!
Leonidas
2003-10-17, 01:59:33
Original geschrieben von Gast
Die steppings vor dem C0 waren bezüglich ecc ja in Ordnung! Wer weis genau ob opterons (habe nix finden können) überhaupt im C0 ausgeliefert werden!
Alle ausgelieferten sind C0. Die davor waren nur Samples.
> Genauer pls. Wer muß genau was machen?
Meines Wissens tritt der Bug nur bei 333MHz auf. Ein Fix wäre im BIOS ein anderes (langsameres) Memory-Timing anzuschalten bzw. langsamere DIMMs zu verwenden.
Wenn das BIOS eine Möglichkeit hat die DataMask Funktion abzuschalten ginge es auch damit (halte ich aber für unwahrscheinlich). Ein Systemhersteller könnte evtl. eine solche Option vom MB Lieferanten fordern.
Wenn der Kunde x4 organisierte DIMMs (die mit 18 Memorybausteinen) verwendet braucht man die Data-Mask Pins des Opteron als DQS pins. In dem Fall mus das BIOS sowieso DisDatMsk setzen, was den Fehler vermeidet. D.h. verbaut ein Systemhersteller nur "grosse" DIMMs ist er auf der sicheren Seite.
Desti
2003-10-17, 16:44:33
Original geschrieben von Leonidas
Alle ausgelieferten sind C0. Die davor waren nur Samples.
Der Opteron 240 und 140 wurden defnitiv auch als B3 ausgeliefert. Als vollwertige PIB Ware.
Original geschrieben von Desti
Der Opteron 240 und 140 wurden defnitiv auch als B3 ausgeliefert. Als vollwertige PIB Ware. So steht’s (auslesung) auch auf meinen mir vorliegenden cpus! aber auch wen es c0 wären, wäre es egal da bestimmt kein PC 333 RAM in solchen Servern verbaut wird :)
Leonidas
2003-10-18, 17:14:57
Danke für Eure Antworten.
Leonidas
2003-10-27, 23:56:04
Hier wird nix vergessen: Es kommt in die heutigen News.
PS: Warum kein DDR333 in Server? Ist von der JEDEC für ECC und registrieren Speicher spezifiziert.
KEINPLAN
2003-10-28, 12:43:25
Original geschrieben von Leonidas
Hier wird nix vergessen: Es kommt in die heutigen News.
PS: Warum kein DDR333 in Server? Ist von der JEDEC für ECC und registrieren Speicher spezifiziert. Beim Server ist es ehr so das auf bewährte Sachen gesetzt wird! Kurze latenzen beim RAM sind ja auch nicht zu verachten. Wir nehmen da lieber 266 cl2, durch Dual channel ja auch kein Bandbreiten prob!
Vielen Dank für die Richtigstellung wegen dem Stepping, und das du es vergißt hätte ich eh nicht gedacht :)
Leonidas
2003-10-28, 14:08:05
Original geschrieben von KEINPLAN
Beim Server ist es ehr so das auf bewährte Sachen gesetzt wird! Kurze latenzen beim RAM sind ja auch nicht zu verachten. Wir nehmen da lieber 266 cl2, durch Dual channel ja auch kein Bandbreiten prob!
Aha.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.