News Aktualisierte Fehlerliste für AMD Prozessoren inkl. D0-Stepping
- Ersteller Nero24
- Erstellt am
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.066
- Renomée
- 10.446
Mit der Einführung des <a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=362976">AMD Athlon II X2</a> und des <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1243891692">AMD Six-Core Opteron 2400 Serie</a> wurden zugleich auch zwei neue Prozessor-Steppings auf den Markt gebracht. Während die bisherigen 45 nm Produkte auf Deneb-Basis auf das Stepping RB-C2 hörten (RB ist die Maske, C2 das eigentliche Stepping), wird der Athlon II X2 wie <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1242222101">berichtet</a> mit einer eigenen Maske hergestellt, um aufgrund des fehlenden L3-Caches kleinere Brötchen backen zu können im wahrsten Sinne und damit die Produktionskosten zu minimieren. Daher hört die Die-Bezeichnung beim Athlon II X2 auf DA-C2. Beim Six-Core Opteron mit Codenamen Istanbul dagegen wurde gleich ein komplett neues Stepping namens D0 (genauer: HY-D0) eingeführt, das derzeit ausschließlich im Six-Core Opteron 2400 und 8400 zum Einsatz kommt, demnachst aber als Quad-Core Variante auch in den <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1244716339">Einzelsockel-Opterons 138x "Suzuka"</a>.
<center><img src="/news_images/errata20090601.png" border="1" height="1274" width="550" alt="K10 Errata-List"></a></center>
Interessanterweise hat AMD trotz gleicher Stepping-Bezeichnung wie beim bisherigen Phenom II beim Athlon II die Gelegenheit genutzt ein paar Bugs zu fixen, z.B. Erratum 348 <i>"Processor On-die Termination Resistance is Higher than Specification"</i>, während sich einige von selbst dadurch erledigt haben, dass der Athlon II keinen L3-Cache mehr besitzt. Dafür schleppt der Athlon II aber einen Bug exklusiv mit sich herum: Erratum 395 <i>"Incorrect Data Masking in Ganged DRAM Mode"</i>. Ein triftiger Grund den Athlon II ausschließlich im Unganged Betriebsmodus des IMC zu betreiben.
Etwas anders sieht die Sache beim Six-Core Opteron "Istanbul" aus. Als neues Produkt mit neuen Features ist es logisch, dass der Fehlerteufel ein paar Mal häufiger zugeschlagen hat. Auf den ersten Blick ins Auge stechen Erratum 374 <i>"Processor Read From L3 Cache May Return Stale Data"</i> und Erratum 384 <i>"DRAM Prefetch May Cause System Hang When Probe Filter is Enabled"</i>. Auf den ersten Blick klingt das vernichtend. Wenn ein Prozessor veraltete Daten aus dem L3-Cache holt, wäre das ein GAU, der von falschen Ergebnissen bis zum Absturz führen kann. Und dass ausgerechnet ein aktivierter Probe-Filter - ein neues Feature beim Istanbul, das Marketing technisch unter der Bezeichnung HT-Assist läuft - zu einem Absturz führen kann, war sicherlich auch nicht gewollt. In beiden Fällen empfiehlt AMD den BIOS-Programmierern ganz bestimmte Parameter in den internen Konfigurationsregistern des Prozessors zu setzen, um die Umstände, unter denen der Fehler auftreten kann, gar nicht erst zuzulassen. Ganz normale Vorgehensweisen also, wie sie bei jedem Prozessor dutzende Male angewendet werden müssen, um ihn in der Praxis fehlerfrei arbeiten zu lassen. Solange das nicht massiv auf die Leistung drückt wie beim berüchtigten Erratum 298 des ersten K10 auch kein Beinbruch. Beide Errata, sowie noch ein paar andere hinzu gekommene, sollen mit kommenden Steppings gefixt werden.
<b>Links zum Thema:</b><ul><li><a href="http://support.amd.com/us/Processor_TechDocs/41322.pdf" target="_blank">AMD K10 Revision Guide</a></li><li><a href="http://support.amd.com/us/Processor_TechDocs/31116-Public-GH-BKDG_3-28_5-28-09.pdf" target="_blank">MSR-Register des K10</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1242222101">AMD doch mit nativen Dual-Cores und weiteren Masken?</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1243891692">Sechs-Kern Opteron Istanbul Reviews und Analyse</a></li><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=362976">Phenom II X2 550 BE & Athlon II X2 250 - Aufstand der Zweikerner</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1204017077">AMD TLB-Bug Erratum 298 endlich dokumentiert</a></li></ul>
<center><img src="/news_images/errata20090601.png" border="1" height="1274" width="550" alt="K10 Errata-List"></a></center>
Interessanterweise hat AMD trotz gleicher Stepping-Bezeichnung wie beim bisherigen Phenom II beim Athlon II die Gelegenheit genutzt ein paar Bugs zu fixen, z.B. Erratum 348 <i>"Processor On-die Termination Resistance is Higher than Specification"</i>, während sich einige von selbst dadurch erledigt haben, dass der Athlon II keinen L3-Cache mehr besitzt. Dafür schleppt der Athlon II aber einen Bug exklusiv mit sich herum: Erratum 395 <i>"Incorrect Data Masking in Ganged DRAM Mode"</i>. Ein triftiger Grund den Athlon II ausschließlich im Unganged Betriebsmodus des IMC zu betreiben.
Etwas anders sieht die Sache beim Six-Core Opteron "Istanbul" aus. Als neues Produkt mit neuen Features ist es logisch, dass der Fehlerteufel ein paar Mal häufiger zugeschlagen hat. Auf den ersten Blick ins Auge stechen Erratum 374 <i>"Processor Read From L3 Cache May Return Stale Data"</i> und Erratum 384 <i>"DRAM Prefetch May Cause System Hang When Probe Filter is Enabled"</i>. Auf den ersten Blick klingt das vernichtend. Wenn ein Prozessor veraltete Daten aus dem L3-Cache holt, wäre das ein GAU, der von falschen Ergebnissen bis zum Absturz führen kann. Und dass ausgerechnet ein aktivierter Probe-Filter - ein neues Feature beim Istanbul, das Marketing technisch unter der Bezeichnung HT-Assist läuft - zu einem Absturz führen kann, war sicherlich auch nicht gewollt. In beiden Fällen empfiehlt AMD den BIOS-Programmierern ganz bestimmte Parameter in den internen Konfigurationsregistern des Prozessors zu setzen, um die Umstände, unter denen der Fehler auftreten kann, gar nicht erst zuzulassen. Ganz normale Vorgehensweisen also, wie sie bei jedem Prozessor dutzende Male angewendet werden müssen, um ihn in der Praxis fehlerfrei arbeiten zu lassen. Solange das nicht massiv auf die Leistung drückt wie beim berüchtigten Erratum 298 des ersten K10 auch kein Beinbruch. Beide Errata, sowie noch ein paar andere hinzu gekommene, sollen mit kommenden Steppings gefixt werden.
<b>Links zum Thema:</b><ul><li><a href="http://support.amd.com/us/Processor_TechDocs/41322.pdf" target="_blank">AMD K10 Revision Guide</a></li><li><a href="http://support.amd.com/us/Processor_TechDocs/31116-Public-GH-BKDG_3-28_5-28-09.pdf" target="_blank">MSR-Register des K10</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1242222101">AMD doch mit nativen Dual-Cores und weiteren Masken?</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1243891692">Sechs-Kern Opteron Istanbul Reviews und Analyse</a></li><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=362976">Phenom II X2 550 BE & Athlon II X2 250 - Aufstand der Zweikerner</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1204017077">AMD TLB-Bug Erratum 298 endlich dokumentiert</a></li></ul>
Ähnliche Themen
