AMD veröffentlicht Errata-Liste des Shanghai

Bei der Einführung des K10 Barcelona hatte AMD den Zorn der Öffentlichkeit auf sich gezogen, da man es versäumt hatte einen bekannten Bug, der immerhin so schwerwiegend war, dass <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1196941037">die Auslieferung einer ganzen CPU-Familie für den Serverbereich gestoppt werden musste</a>, zu dokumentieren. Drei Monate lang. Erst kurz vor der Einführung des fehlerbereinigten B3-Steppings <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1204017077">wurde auch die so genannte Errata-Liste (von lat. Erratum: Fehler) ergänzt</a>. Eine unglückliche Vorgehensweise, die damals viel Raum für Gerüchte, Mythen und Spekulationen ließ.

Jetzt bei der <a href="http://www.planet3dnow.de/vbulletin/showthread.php?p=3779283">Einführung des neuen 45 nm Quad-Core Opteron mit Codenamen Shanghai</A> ist AMD offenbar bemüht alles richtig zu machen. Die Leistungswerte der neuen CPU konnten bereits fast durchgehend überzeugen und nun hat AMD auch noch die <a href="http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/41322_PUB_Rev3.34v4.pdf" target="_blank">Errata-Liste</a> der K10-Familie auf den neuesten Stand gebracht.

<center><img src="/news_images/errata20081116.png" alt="AMD veröffentlicht Errata-Liste des Shanghai" border="1"></center>

Die Fehler- und Fehlerkorrekturen sind nicht nur für den Shanghai relevant, sondern auch für die kommenden Deneb-CPUs. Dabei fällt auf, dass AMD bei den neuen 45 nm CPUs (in der Liste als RB-C2 geführt) nicht nur das Herstellungsverfahren verkleinert und die Leistung verbessert hat, sondern die Gelegenheit genutzt hat auch etliche Bugs zu eliminieren - praktisch sämtliche Fehler der bisherigen Steppings, die nicht mit "No fix planned" gekennzeichnet waren. Die meisten davon waren akademischer Natur, Fehler mit denen der Anwender niemals in Berührung kommt, da sie lediglich BIOS-Programmierer und Compiler-Entwicklung interessieren müssen. Allerdings waren auch Fehler dabei wie das Erratum 355 - "DRAM Read Errors May Occur at Memory Speeds Higher than DDR2-800" - welche für Endkunden durchaus ärgerliche Folgen haben konnten - nämlich, dass ein Phenom mit DDR2-1066 Speicher, für die er offiziell eine Freigabe besitzt, unter Umständen nicht stabil arbeitete. Dieser Fehler ist nun mit dem C2-Stepping gefixt, ebenso wie die unbrauchbaren Temperatur-Messungen der internen Dioden ("Inaccurate Temperature Measurement").

Apropos C2-Stepping. Seit einigen Monaten schon geistern immer wieder <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1218100243">Benchmarks und Tests von Deneb-Samples</a> durch den Blätterwald, vorwiegend veröffentlicht von Webseiten aus Fernost. Diese CPUs besaßen noch das Stepping C0, das es niemals in den Verkauf geschafft hat. Insofern sind die damaligen Leistungs- und Verbrauchs-Tests für eine Standort-Bestimmung der 45 nm Phenom-Prozessoren, wie sie im Januar auf den Markt kommen werden, weitestgehend irrelevant.

Doch zurück zur Errata-Liste. Natürlich sind auch ein paar neue Bugs hinzu gekommen. Einige davon wurden erst jetzt entdeckt, welche die gesamte K10-Reihe betreffen (Stepping BA, B2, B3, C2), einige dagegen betreffen nur den Shanghai bzw. Deneb. Ein paar Sachen sind dabei - z.B. "DRAM May Fail Training on Cold Reset" - welche Endkunden gelegentlich über den Weg laufen könnten, einige werden in der Praxis niemals auftreten - z.B. "System May Hang if Core Frequency is Even Divisor of Northbridge Clock" - solange AMD keine Prozessoren herstellt, bei denen das der Fall ist. Relevant könnte es höchstens für (Northbridge-)Übertakter oder (Kern-)Untertakter werden, wenn sie Kernfrequenz und Northbridge-/L3-Takt zufällig auf die selbe Frequenz setzen.

Hi,

AMD arbeitet eindeutig solider und ist in der Informationspolitik redlicher als zuvor.

Der Shanghai ist ja fast schon was der R700 im Vergleich zum R600 ist....


Greetz
neax

Tja...manchmal muss man sich scheinbar eben wirklich erstmal so richtig auf die Fresse legen, bevor man merkt, dass eventuell doch das ein oder andere ändernswert wäre...

Mir gefällt diese neue Informationspolitik auch besser, macht das Unternehmen einfach wieder "etwas" Seriöser

Doch sehr schön, wie viele Fehler korrigiert wurden. Bei allem Lob für die Informationspolitik muss man natürlich auch sagen, dass schnelle offene Karten einfach sind, wenn man keine kritischen Fehler vor sich hat. Bewähren tut sich die Informationspolitik dagegen, wenns wirklich drauf an kommt.

Lustig finde ich erratum 370. Zwar nicht mehr für C2 relevant, aber immerhin. Selbst mit DDR2-800 ist unter etwas erschwerten Bedingungen (jitter) Instabilität möglich. Zeigt eigentlich nur wieder sehr schön, dass Qualität beim Ram einem immer wichtiger sein sollte, als 3% Mehrleistung durch Super-Duper-Timings etc.

neax schrieb:

Hi,

AMD arbeitet eindeutig solider und ist in der Informationspolitik redlicher als zuvor.

Der Shanghai ist ja fast schon was der R700 im Vergleich zum R600 ist....


Greetz
neax

Zum Vergrößern anklicken....

Man kann vielleicht sagen, dass der Shanghai das haelt, was der Barcelona versprochen hat - aber das gilt vorerst nur fuer den Serverbereich.

Alles andere, denke ich, muss man abwarten!

Aber bergruessen muss man, dass AMD so frueh die Errata Liste veroeffentlicht.
Das spricht hoffentlich fuer eine offenere, ehrlichere Informationspolitik..und ist hoffentlich nicht nur damit begruendet, dass sie gerade so gut fuer AMD aussieht (viele alte Errata wurden beseitigt...)...

Na da kann ja vieles nur mehr besser werden!
Dann vergess ich meine Überlegungen um einen 9950 Black doch gleich wieder

neax schrieb:

Hi,

AMD arbeitet eindeutig solider und ist in der Informationspolitik redlicher als zuvor.

Der Shanghai ist ja fast schon was der R700 im Vergleich zum R600 ist....


Greetz
neax

Zum Vergrößern anklicken....

Im Moment scheint AMD solider zu arbeiten, allerdings läßt das keine Langzeitprognosen zu. Wir wissen nicht, welche Anstrengungen die Firma zur Einhaltung dieser Verfahrenslinie unternehmen mußte bzw. unternommen hat, um den Werdegang derart positiv zu gestalten. Schon mit der nächsten CPU oder dem nächsten Problem kann schon alles anders sein.

Wünschesnwert wäre allerdings eine solidere Verfahrensweise auch für die Zukunft - das macht die Einschätzungen berechenbarer und damit für potentielle Serverkunden attraktiver.

Im Grunde aber konnte es nur noch besser werden, das sollte man nicht vergessen.

Wirklich vorbildlich, dass der Revision Guide für die 10h Familie schon auf das C2 Stepping angepasst wurde.

Dieses eine Mal ist man selbst Intel voraus. Da herrscht rund um das Specification Update des Core i7 noch Verwirrung: Klick

Intel sollte sich aber langsam einmal sputen die technischen Dokumente fertigzustellen. Die Core i7 sind schließlich schon am Markt.

SPINA schrieb:

Intel sollte sich aber langsam einmal sputen die technischen Dokumente fertigzustellen. Die Core i7 sind schließlich schon am Markt.

Zum Vergrößern anklicken....

Ja, aber offiziell erst ab Morgen.

Selbst wenn sich sonst keiner um das Verkaufsverbot schert, wird sich wohl Intel selbst ganz brav ans eigene Emargo until .... Datum halten

ciao

Alex

Ich könnte mir auch vorstellen, daß durch das Beheben dieser Bugs auch die Leistung etwas gesteigert wurde. Sah man ja exemplarisch am TLB-Bug: Ungefixed und ohne BIOS-Workaround instabil, mit Abschaltung der bestroffenen Stelle stabil, aber langsamer. Wird die betroffene Stelle aber repariert und funktioniert dann so wie sie soll, ist man wieder auf der ursprünglichen Performance.

Bei den meisten anderen Bugs/Errata kennen wir ja gar nicht die "ursprüngliche Leistung", weil ja gleich von vornherein alles im BIOS umschifft wurde, aber es ist ja nicht gesagt, daß bei der Gelegenheit auch Performance flöten gegangen war. Z.B. bei dieser Geschichte "DDR800 kann instabil werden" wurde es im BIOS doch wahrscheinlich dadurch gelöst, daß einige Timings verlängert wurden.

Bei dieser Latte von Bugfixes sind bestimmt auch ein paar Prozentchen (oder meinetwegen nur Promille) Leistungsverbesserung zusammengekommen.

Und ganz ehrlich, ich hab auch ein besseres Gefühl, eine fehlerarme CPU zu benutzen, auch wenn das objektiv natürlich unsinnig ist, aber Barcelona kam einem manchmal wie ein repariertes Unfallauto vor (aber war wohl eher eins dieser berüchtigten Montagsautos).

Intel verschleiert seine Probleme gern mal - während die die AMD Bugs lautstark hervorheben - der TLB-Bug wurde nur "hochgepauscht" - ist offiziell nie irgendwo in der freien Welt aufgetreten - nur im Labor !

Auf Arbeit haben wir auch einige BA-Opterons ohne Patch - laufen 24/7 ohne Probleme unter Srv03x64.

Fehlerfreie CPU ? - der Core7 hat mehr als 400 Bugs drin, gut die meisten sind Labor-Bugs aber .....

Ne, Crashtest, man kann Intel nun wirklich nicht vorwerfen, sie hätten die AMD-Bugs gehyped. Wenn einer den TLB-Bug gehyped hat, dann AMD selber, bis hin zum Opteron-Auslieferungsstop. Wenn AMD nischt gesagt hätte, hätte auch niemand was gemerkt, bis auf die Abstürze unter den speziellen Bedingungen, die bisher niemand so recht kennt. Ob z.B. erratum 298 nun ein Labor-Problem oder ein real world Problem ist, kann aber am Ende auch nur AMD sagen. Da dazu nur wenig konkrete Infos durchgesickert sind, würde ich denken, sie haben es wenn dann auch nur sehr wenigen Leuten erzählt.

In einem Produktivsystem einen BA Opteron ohne TLB-Patch laufen zu lassen, ist fahrlässig, wobei ich denken würde, dass ein aktuell gepatchtes OS trotzdem den Patch aktiviert......

Opteron hatte Recht. Intel hat den Schleier gelüftet und die Links auf der Core i7 Support Site sind nicht mehr verwaist.

Der Core i7 hat erwartungsgemäß im ersten Stepping eine ganze Liste an Erratas. AAJ41 und ein paar andere Bugs klingen unschön, aber insgesamt geht es.

Aber es war eh schon immer klüger bei einem neuen Prozessorrelease erst das Nachfolgestepping abzuwarten. Auch bei Intel.

warum soll man ein System ausbremsen (rd 20%) damit ein hypot. Bug nicht auftritt ? - Unsere Admins (Beamte A15) lassen die Finger von BIOS-Updates, da die Wahrscheinl., dass beim Update etwas schief geht höher ist, als dass dieser "Bug" auftritt - und so ein 8-Sockel-Opteron-Board von Tyan (m4985 + s4985) kostet mal nebenbei rd 1400Euro, neuer BIOS-Chip rd 50Euro (inkl. Supportanfrage dazu) + Ausfallkosten

unser Hauptserver, 8 schöne 8350er BAs ist erst einmal "abgestürzt" - in einem Jahr - weil ein Mitarbeiter ausversehen die Hauptsicherung gekillt hat - die USV war nach 8min alle aber der Server konnte nicht schnell genug runterfahren.

für alle "Fehlerfrei"-CPU-Fans:
kauft euch keine CPU, damit seit Ihr fehlerfrei ! sonst muss man halt mit einigen Fehlern leben - wie bei Windows, wo einige Fehler erst mit neuem OS "gelöst" werden

Windows ? - da gibts keine "K10-Bug" Lösung von MS
Linux ? - hammar nisch

ps viele wollen doch auch nich die PCI-Bus Leistung massiv senken mit Biosupdate nur weil nVIDIA ein paar Patente verletzt hat oder ?

Crashtest schrieb:

warum soll man ein System ausbremsen (rd 20%) damit ein hypot. Bug nicht auftritt ?

Zum Vergrößern anklicken....

Wenn dir Rechenleistung wichtiger ist als korrekte Ergebnisse. Kannst du nachweisen, dass der Bug in der Realität nicht auftritt? Weißt du, welche Auswirkungen er genau haben kann?
Btw, du plenkst.

Crashtest schrieb:

warum soll man ein System ausbremsen (rd 20%) damit ein hypot. Bug nicht auftritt ? - Unsere Admins (Beamte A15) lassen die Finger von BIOS-Updates, da die Wahrscheinl., dass beim Update etwas schief geht höher ist, als dass dieser "Bug" auftritt -

Zum Vergrößern anklicken....

Verbeamtete Admins mögen das so sehen, ich halte das dennoch für eine fahrlässige Einstellung. Auch Serverhardware gehört aktuell gehalten, wenn nicht per Wartungsvertrag, dann muss man das eben selber "riskieren". Schau Dir doch mal die Errata-Listen an, da gehört ein System aktualisiert IMHO. Das gleiche gilt für Server-Software, wo nicht aktualisierte OS und Anwendungen zu einem erheblichen Sicherheitsrisiko werden, solange zumindest Teile des Netzes Verbindung nach außen hat. Und bei Softwareaktualisierungen geht man als Admin ein noch viel größeres Risiko ein, dass man sich Probleme einhandelt. Trotzdem wäre alles andere fahrlässig.

für alle "Fehlerfrei"-CPU-Fans:
kauft euch keine CPU, damit seit Ihr fehlerfrei ! sonst muss man halt mit einigen Fehlern leben - wie bei Windows, wo einige Fehler erst mit neuem OS "gelöst" werden

Windows ? - da gibts keine "K10-Bug" Lösung von MS
Linux ? - hammar nisch

Zum Vergrößern anklicken....

Sicher mit Windows? Für Vista jedenfalls wurde das mal unterstellt, dass aktuelle patch-level die entsprechenden Einstellungen vornehmen, was prinzipiell möglich ist.....

Es soll zwar Gerüchte über ein Treiber für Vista/Srv08 geben, der die notwendigen MSR-Werte als Fix für den TLB-Bug setzt, aber nur Gerüchte ....

Falsch rechnen ? - das ham einige Intel Prozessoren mal (P60 & co)
die meisten "Bugs" beziehen sich u.a. auf DDR2-Ram über 667MHz, mit mehr laufen die Opterons bei uns auf Arbeit nicht (16-Kanal DDR2 im NUMA reichen aus !)

Crashtest schrieb:

Falsch rechnen ? - das ham einige Intel Prozessoren mal (P60 & co)
die meisten "Bugs" beziehen sich u.a. auf DDR2-Ram über 667MHz, mit mehr laufen die Opterons bei uns auf Arbeit nicht (16-Kanal DDR2 im NUMA reichen aus !)

Zum Vergrößern anklicken....

Du weißt schon, was der TLB ist, und was ein fehlerhaft arbeitender TLB bewirken kann?

der TLB-Bug kann, wenn er auftritt einiges anrichten, aber genauso kann ein Chip auf dem Mainboard durchbrennen oder ein Elko platzen ... solange keine Berichte über tatsächlich wild aufgetretenen TLB-Bug vorliegen ist es zwar möglich aber eher unwahrscheinlich .... eher habsch nen 6er im Lotto ....

aber es gibt "schlimmere" Probleme einiger Prozessoren (egal Intel oder AMD) :

manchmal funktioniert die Temperaturmessung nicht richtig und gibt zuniedrige Werte aus : ist der Prozis dann zu heiß - fallen ggf. die Anstehende Senkung des Takts/Volt aus - Schäden können folgen.

oder bei einigen K8s (Rev. E-G) speert der Prozi seine "PCI-Geräte" (idR. Bus 0 Dev 24 Funk 0-3) sodass Monitorprogramme (wie CPUZ, HWMoni, Everest ....) keine Temperaturdaten auslesen können (is bis jetzt noch nicht bei den Rev. B - D aufgetreten)

Crashtest schrieb:

der TLB-Bug kann, wenn er auftritt einiges anrichten, aber genauso kann ein Chip auf dem Mainboard durchbrennen oder ein Elko platzen ... solange keine Berichte über tatsächlich wild aufgetretenen TLB-Bug vorliegen ist es zwar möglich aber eher unwahrscheinlich .... eher habsch nen 6er im Lotto ....

Zum Vergrößern anklicken....

Wenn du darauf deine Daten verwetten tust. Ich würde wahrscheinlich böse eins auf den Deckel bekommen, wenn ich das versuchen würde.

Crashtest schrieb:

der TLB-Bug kann, wenn er auftritt einiges anrichten, aber genauso kann ein Chip auf dem Mainboard durchbrennen oder ein Elko platzen ... solange keine Berichte über tatsächlich wild aufgetretenen TLB-Bug vorliegen ist es zwar möglich aber eher unwahrscheinlich .... eher habsch nen 6er im Lotto ....

Zum Vergrößern anklicken....

Na so selten ist der nicht gerade und durch andere Fehler resultierenden Geschwindigkeitseinbussen sind auch nicht gerade verkraftbar.
Siehe Nov07 test Phenom9500, nene lieber keinen davon besitzen.