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...

-> Kommentare

It is not in the Palomino core. I wish before people spread word about these kinds of bugs they would look into which revisions of the CPUs are effected.

Non-conformance: When the logical address designated by the INVLPG instruction is mapped by a 4-MB page mapping and LA[21] is equal to one it is possible that the TLB will still retain translations after the instruction has finished executing.
Potential Effect on System: The residual data in the TLB can result in unexpected data access to stale or invalid pages of memory.

The INVLPG erratum in the revision guide has nothing to do with Win2k patch issue

An issue has been identified that could result in the corruption of video data shared between AGP graphics adapters and AMD Athlon™ or AMD Duron™ processors, including the AMD Athlon™ MP processor when running Microsoft Windows®2000 Professional, Windows®2000 Server, or Windows®2000 Advanced Server. This issue is independent of system chipset and has been observed when running Ziff-Davis 3D Winbench™ 2000 and Mad Onion 3DMark™ 2000 in benchmarking mode.

Um eines vorweg zu nehmen: Wir gehen nicht davon aus, dass die Ursache des Phänomens in der CPU selbst begründet liegt. Wäre dem so, wäre Windows XP auch betroffen, da Windows XP auch Large Pages benutzt. In Windows XP tritt dieses Phänomen aber nicht auf.

Der Large Pages Issue unter Win2k tritt bei allen K7 CPUs auf. Inklusive Athlon XP

Was Linux angeht: Wir wissen noch nicht, was die Ursache ist, warum Linux ähnliche Phänomene zeigt wie Windows 2000. Wir konnten das Phänomen intern noch nicht reproduzieren. Bevor wir dies nicht tun können, wäre jede Aussage, was die Ursache ist, reine Spekulation. Insofern können wir auch (noch) nicht sagen, welche Prozessoren betroffen sind, wenn überhaupt einer betroffen ist.

Die Nutzung von Large Pages abzuschalten, hat offensichtlich bei einigen Usern das Problem behoben. Doch das Abschalten der Large Pages ist bekannt dafür, viele andere Dinge auch zu maskieren. Es mag im Moment helfen, stellt jedoch keine dauerhafte Lösung dar.

Wir nehmen die Angelegenheit jedoch sehr ernst und arbeiten angestrengt daran, das Phänomen intern nachzustellen, um eine Lösung anzubieten.

Sollte jemand ähnliche Phänomene mit seiner CPU haben, sollte er die technische Hotline kontaktieren.

Update:
Mittlerweile hatten wir auch die Gelegenheit mit Daniel Robbins, Chief Architect/President von Gentoo Technologies Inc. zu sprechen, welche die Extended Pages Geschichte veröffentlicht hatten. Wie es scheint ist hier mittlerweile ein Umschwenk in Gange, der die AMD Prozessoren in der Linux-Geschichte entlastet:

The issue we are talking about is a subtle interaction between speculative writes, extended paging and the GART (not a CPU bug, this was a misunderstanding). This quirk results in corruption of AGP and system memory, and it's really the responsibility of the Linux kernel and drivers to make sure that this issue doesn't happen. See my post at GeoCrawler which contains an update including an official explantion from AMD of a problem that can happen and may be happening to Linux people. Follow the thread and you'll see that it's a real issue. It is a very interesting problem.

The Linux kernel developers are currently investigating this speculative write/GART interaction to see if it could affect Linux users. So far, the consensus seems to be that it *does* affect Linux AGP users and developers are currently trying to find a solution that doesn't not hurt performance as "mem=nopentium" (turning off extended translation) does.

Die Intel-Chipsätze dagegen kamen bisher fast immer mit einem blauen Auge davon. Die gröbsten Bugs, mit denen durchaus auch Intel zu kämpfen hatte, wurden meist rechtzeitig erkannt und vor Markteinführung oder mit einem Rückruf gefixt. Nun jedoch scheint es auch Intel erwischt zu haben! Wie The Inquirer schreibt mußte Intel einen Bug im i850 und i860 Chipsatz einräumen, der ebenfalls die PCI-Performance negativ beeinflußt:

Both the Intel 850 and the 860 chipsets have bugs that affect IDE drives which means, for example, your ATA 100+ drive only manages around 80Mb burst rate and no higher This is what Intel calls an erratum and the rest of us who try not to choke over Latin words call a bug, and never a sighting nor a pretzel.

-> Kommentare