News AMD aktualisiert Errata-Liste

<div class="newsfloatleft"><a href="http://www.amd.com"><img src="http://www.planet3dnow.de/photoplog/file.php?n=9124" border="1" alt="AMD Logo "The future is fusion""></a></div>AMD hat seinen <a href="http://support.amd.com/de/Processor_TechDocs/41322.pdf" target="b">"Revision Guide for AMD Family 10h Processors"</a> auf Version 3.74 aktualisiert. Darin tauchen erstmals auch die neuen <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1277274757">AMD Opteron 4100</a> für den Sockel C32 auf. Interessanterweise gibt Tabelle 6 darüber Auskunft, dass nicht nur das aktuelle Stepping D1 als AMD Opteron 4100 verkauft wird, sondern auch alte Istanbul-Dies (Stepping D0). Dies könnten die AMD Opteron 4100 mit nur vier Kernen sein, welche kein C1E beherrschen und auch keine LV-DDR3 DIMMs ansteuern können. Außerdem schafft der aktualisierte Revision Guide Klarheit bei den neuen mobilen Prozessoren der Danube und Nile Plattform. Entgegen einiger Spekulationen handelt es sich bei den neuen Prozessoren mit einer 64-bit FPU nicht um irgendwelche K8 Derivate, die auf den aktuellen 45nm Prozess geshrinkt wurden, sondern um "echte" K10, bei denen die 128-bit FPU nur mit halber Breite arbeitet (siehe unten stehendes Bild). Das Design der K10 Kerne lässt offensichtlich diese Teildeaktivierung zu. Man sollte aber dennoch aufpassen, da die älteren Prozessoren der Congo Plattform, die wirklich alte K8 @ 65nm SOI (Revision DH-G2 "Lima" und BH-G2 "Brisbane") sind, auch weiterhin verkauft werden. Leider unterscheidet sich die Namensgebung nur minimal. Die Neo Prozessoren mit K10 Innenleben sind an dem K im Nummernschema erkennbar (z.B. AMD Turion II Neo <b>K</b>665), oder noch einfacher am verbauten DDR<b>3</b> Arbeitsspeicher. Außerdem steht damit fest, dass die neuen Prozessoren der Danube und Nile Plattform auf der Regor- (DA) bzw. Propus-Maske (BL) im C3 Stepping basieren.
<p style="clear:left">
<img src="http://www.planet3dnow.de/photoplog/file.php?n=10128&w=o">


<b>Die vollständige Errata-Liste:</b>

<img src="http://www.planet3dnow.de/photoplog/file.php?n=10127&w=o"></p>

Es sind nur 2 neue Errata (419 und 486) hinzugekommen, die aber nur die neuen <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1269853253">AMD Opteron 6100</a> und <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1277274757">4100</a> betreffen. So kann es laut Errata 419 vorkommen, dass ein Opteron 4100 sich als Package AM2r2 (Sockel AM2+) oder AM3 Prozessor meldet. Dieser Fehler kann aber durch ein aktuelles BIOS behoben werden. Das zweite neue Errata (486) betrifft falsche Angaben im "AMD Family 10h Server and Workstation Processor Power and Thermal Data Sheet" zu den elektrischen Eigenschaften der Sockel G34 Prozessoren. Bei den neuen Prozessoren gibt AMD zusätzlich zur TDP auch eine darüberliegende Max Power an, auf die sich die maximale Stromstärke (IDD Max) bei diesen Prozessoren eigentlich beziehen soll. Es handelt sich also nicht um einen Fehler im Silizium. In einem neuen Release soll dieser Fehler behoben sein.

<blockquote><center><i>"The AMD Family 10h Server and Workstation Processor Power and Thermal Data Sheet, order #43374 for G34r1 and C32r1 OPNs incorrectly documented an “IDD Max” value that was based on current at “Thermal Design Power” (TDP). The maximum current for these processors would be properly defined at “MaxPower” and documented as the “Thermal Design Current” (TDC)."</i></center></blockquote>

Genauen Beobachtern wird sicher der dritte grüne Strich aufgefallen sein. Das Errata 319 ist allerdings nicht neu hinzugekommen. AMD hat hier die Beschreibung des Fehlers korrigiert. Laut AMD soll dieser Fehler nur bei Prozessoren mit AM2r2 (Sockel AM2+), Fr2 (1207), Fr5 (1207) oder Fr6 (1207) (Sockel F) Package auftreten. Also werden die Temperaturen bei aktuellen Desktop-Prozessoren wohl doch korrekt ausgelesen.

Auch zum Errata #327 "HyperTransport Link RTT Specification Violation" gibt es Neuigkeiten. AMD hat sich nun abschließend dazu entschieden, doch keinen Fix für diesen Fehler in ein mögliches neues Stepping zu integrieren.

<b>Links zum Thema:</b>
<ul><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1272314190">Neue AMD Errata-Liste inkl. Phenom II X6</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1277274757">AMD launcht Opteron 4100 Serie mit 4 und 6 Kernen</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1269853253">AMD launcht Opteron 6100 Serie mit 8 und 12 Kernen</a></li></ul>

Womit also im Umkehrschluss festzuhalten wäre, dass die Temperaturen der Thubans nun doch korrekt ausgelesen sind? Oder ist somit das Thema Temperaturdiode Mainboard vs. Core-Temp mit ca. 10-11°C Unterschied immer noch nicht vom Tisch?

Auf den Boards AM3 werden die wohl richtig ausgelesen, nicht aber auf AM2+. Auf der anderen Seite wäre ich trotzdem vorsichtig und würde zu sehen das die Tempanzeige unterhalb von 55° bleibt damit in jedem Fall noch ein bisschen Spielraum übrig ist.

Dr@ schrieb:

Also werden die Temperaturen bei aktuellen Desktop-Prozessoren wohl doch korrekt ausgelesen.

Zum Vergrößern anklicken....

Stechpalme schrieb:

Auf den Boards AM3 werden die wohl richtig ausgelesen, nicht aber auf AM2+.

Zum Vergrößern anklicken....

Liefern die Temperatursensoren nicht teilweise Werte unterhalb der Zimmertemperatur zurück? Es mag also stimmen, dass die Sensoren korrekt arbeiten, aber gerade dann wäre auch eine korrekte "Übersetzung" der Sensorwerte seitens der Mainboards und Software-Tools wünschenswert.

Im Grunde ist es ja egal, orientieren kann man sich auch an aberwitzigen Werten, wenn man sie in Relation zu vergleichbaren Werten betrachtet. Mich stört halt nur, dass die Werte mit der Einheit "Grad Celsius" versehen sind, dann sollten sie näherungsweise auch ebendies wiedergeben.

Wir haben bei uns den Fall nur auf AM2+ Boards nachvollziehen können da wir als Testplattform eben auf ein AM2+ System gesetzt haben. Wir hatten eine AM2+ Plattform eben übrig und hätten ansonsten alles neu kaufen müssen.
Das Problem bei AMD und Programmen wie Core Temp ist einfach das der Tjmax Wert der AMD CPUs schwankend ist. Die eine Charge hat eine tjmax von 70°, die andere von 65°. AMD gibt hier keine festen Werte vor, anders als bei Intel wo bei jeder CPU Reihe klar dokumentiert ist wie hoch die tjmax ist. Die Programme können aber nur mit einem festen Wert rechnen, daher würde ich bei AMD grundlegend keinem Ausleseprogramm trauen das nicht direkt den Bios Wert abliest. Nur welche Programme das wirklich tun, weiß ich nicht, da ich mich darüber noch nicht informiert habe.

Stechpalme schrieb:

Das Problem bei AMD und Programmen wie Core Temp ist einfach das der Tjmax Wert der AMD CPUs schwankend ist. [...]

[...] daher würde ich bei AMD grundlegend keinem Ausleseprogramm trauen das nicht direkt den Bios Wert abliest. Nur welche Programme das wirklich tun, weiß ich nicht, da ich mich darüber noch nicht informiert habe.

Zum Vergrößern anklicken....

Interessant, danke für die Erklärung.

ICh hab mal einen alten Artikel bei Orthy ausgegraben der die Grundzüge erklärt. Trifft nicht 1:1 auf die heutigen CPUs zu, aber im Groben und Ganzen ist es sehr ähnlich wie heute.

Ich fand vor allen Dingen zwei Informationen sehr aufschlussreich. Zum einen, dass die Tjunction bei AMD innerhalb einer Serie unterschiedlich ist, das war mir nicht bewusst. Zum anderen habe ich mit Freude aufgenommen, dass die korrekte Tjunction nicht nur vom BIOS, sondern auch noch auf betriebssystemebene Ausgelesen werden kann, damit steht einer korrekten Temperaturanzeige schon mal nichts Grundlegendes im Weg.

Wie ist das eigentlich mit dem "AMD Overdrive Tool", das sollte ja dann zusammen mit einem AM3-Mainboard korrekte Temperaturwerte liefern?

Die ganze Sensorgeschichte ist aber nicht nur bei AMD unglücklich verzwickt, unter Linux liefern die lm-sensors beispielsweise bei meinem E6600 (B3) auch schon seit Urzeiten zu geringe Werte, selbiges gilt für einen Q6600 (G0). Das Spiel wiederholt sich dann mit den Windowstools, es reicht also nicht einmal eine feste Tjunction innerhalb eines Steppings zu haben. Es ist bedauerlich, dass die Tools mit festen Offsets arbeiten, wenn man stattdessen auch "einfach" (?) die Tjunction auslesen und die Temperaturangabe danach ausrichten könnte.

Ich kann zu AM3 leider in diesem Zusammenhang nur wenig sagen, da ich nie auf einem AM3 System Tests gemacht habe. Das Problem ist auch oft das Board das die Daten der CPU falsch weiter gibt. Trifft auch auf Intel zu, obwohl hier in der Regel die Temps richtig ausgelesen werden, weshalb die meisten ja Tests auf Intel machen und nicht auf AMD.
Einige Hersteller waren erstaunt bei meinen Anfragen das ich auf AMD teste und waren sehr skeptisch.

Mein Q6600 G0 liest auf meinem alten Abit Board die richtigen Temps aus, aber ich weiß von Fällen wo auf bestimmten Boards völliger Unsinn ausgelesen wird. 90° bis 100° werden da angezeigt obwohl die Kühler gut waren und auch richtig aufgesessen haben.

Beim AMD Overdrive Tool kann ich dir auch wenig sagen, da ich mit dem mehr Probleme als sonst was hatte. Aber zumindest hier auf dem Testsystem zeigt es die selben Werte an die auch im Bios angezeigt werden. Von daher gehe ich mal aus das die Anzeige korrekt ist, sofern das Board hier nicht die Fehlerquelle ist.

Stechpalme schrieb:

Die Programme können aber nur mit einem festen Wert rechnen, daher würde ich bei AMD grundlegend keinem Ausleseprogramm trauen das nicht direkt den Bios Wert abliest.

Zum Vergrößern anklicken....

Und nun die 100.000 Euro Frage: Woher weiß das Bios den Wert?

Oh frag mich nicht. Das kann ich dir nicht sagen. Keine Ahnung wie das Bios den Wert ausliest. Ich müsste mich ja mal schlau machen. Aber AMD hat ja bisher noch nicht mal eine Antwort liefern können wie sich ihr Boxed Lüfter selbst regelt.

puntarenas schrieb:

Die ganze Sensorgeschichte ist aber nicht nur bei AMD unglücklich verzwickt, unter Linux liefern die lm-sensors beispielsweise bei meinem E6600 (B3) auch schon seit Urzeiten zu geringe Werte, selbiges gilt für einen Q6600 (G0).

Zum Vergrößern anklicken....

Schon mal in die /etc/sensors(3).conf geschaut? Wenn da falsche Werte für die Umrechnung drin stehen, kommt natürlich nur Müll raus.

Tja da hat sich doch der Fehlerteufel eingeschlichen:

Seite 19 Tab 16 ist fehlerhaft, da NC=01h fehlt und bei NC=00h sich rumtummelt....




Habs an AMD gemailt, mal sehen, wann die dies verbessern ...

PuckPoltergeist schrieb:

Schon mal in die /etc/sensors(3).conf geschaut? Wenn da falsche Werte für die Umrechnung drin stehen, kommt natürlich nur Müll raus.

Zum Vergrößern anklicken....

Danke, manuell konnte ich mir natürlich bereits Abhilfe schaffen. Mein Punkt war nur, dass mir feste Umrechnungswerte wie ein Überbleibsel des 20.JH vorkommen und ich finde, dass die Sensorkalibrierung grundsätzlich aus der Hardware abgelesen werden sollte. Die CPUID muss ich ja beispielsweise auch nicht von Hand eingeben, damit der Rechner mir anzeigt was für einen Prozessor ich habe.

Die Zahl der HTr Fehler überrascht mich immer wieder, wenn ich nach längerer Zeit mal wieder in die Liste schaue.

Kann man die Beobachtung machen, dass der HTr-sync-flood error, den manche user beobachten mussten, weniger geworden ist durch die zunehmende Entdeckung von errata und Lösungen bezüglich HTr?