AMD TLB-Bug Erratum 298 endlich dokumentiert

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Drei Monate ist der AMD Phenom nun schon auf dem Markt und obwohl AMD einen Tag vor der Einführung das Modell 9700 zurückgezogen sowie im Anschluss daran die Auslieferung beinahe der kompletten Quad-Core Opteron-Familie gestoppt hat, waren bei AMD keine offiziellen TechDocs zu dem ominösen TLB-Bug aka Erratum 298 zu finden. Jetzt endlich hat AMD seinen <a href="http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/41322.pdf" TARGET="_blank">Revision-Guide</a> aktualisiert und das Erratum 298 hinzugefügt:<a name="erratum298"></a><ul><i><b>298 L2 Eviction May Occur During Processor Operation To Set Accessed or Dirty Bit</b>

<b>Description</b>
The processor operation to change the accessed or dirty bits of a page translation table entry in the L2 from 0b to 1b may not be atomic. A small window of time exists where other cached operations may cause the stale page translation table entry to be installed in the L3 before the modified copy is returned to the L2. In addition, if a probe for this cache line occurs during this window of time, the processor may not set the accessed or dirty bit and may corrupt data for an unrelated cached operation.

<b>Potential Effect on System</b>
One or more of the following events may occur:
• Machine check for an L3 protocol error. The MC4 status register (MSR 0000_0410) will be equal to B2000000_000B0C0F or BA000000_000B0C0F. The MC4 address register (MSR 0000_0412) will be equal to 26h.
• Loss of coherency on a cache line containing a page translation table entry.
• Data corruption.

<b>Suggested Workaround</b>
BIOS should set MSR C001_0015h[3] (HWCR[TlbCacheDis]) to 1b and MSR C001_1023h[1] to 1b. In a multiprocessor platform, the workaround above should be applied to all processors regardless of silicon revision when an affected processor is present.

<b>Fix Planned</b>
Yes</i></ul>Zudem ist zu lesen, dass der Bug die Steppings DR-BA und DR-B2 betrifft.

Damit fällt die Beschreibung des Erratum 298 leider nicht sehr viel ausführlicher aus, als wir nach Zusammenfügen des Puzzles ohnehin schon berichtet hatten. Im Gegenteil: nach wie vor fehlt für den Anwender der Hinweis in welcher Software-Umgebung (Hardware-Virtualisierung oder genügt der Virtual Mode?) der Bug auftreten kann und ob - wie Anfangs kolportiert - hohe Last nötig ist und falls ja auf wievielen Kernen. Zudem ist in der Beschreibung mit keinem Wort erwähnt, dass der Bug erst ab einer bestimmten Taktfrequenz auftreten kann, obwohl dies der Grund für den zurückgezogenen Phenom 9700 gewesen sein soll. So ist es zwar schön, dass AMD den Bug endlich offiziell dokumentiert, sehr viel schlauer als zuvor ist man jedoch auch nicht.

<a name="erratum309"></a>Blättert man den Revision-Guide noch ein Stück weiter, trifft man auf das Erratum 309, das ebenfalls durch eine Art Race-Condition zweier Komponenten hervorgerufen wird und zu einem Absturz führen kann:<ul><i><b>309 Processor Core May Execute Incorrect nstructions on Concurrent L2 and Northbridge Response</b>

<b>Description</b>
Under a specific set of internal timing conditions, an instruction fetch may receive responses from the L2 and the Northbridge concurrently. When this occurs, the processor core may execute incorrect instructions.

<b>Potential Effect on System</b>
Unpredictable system behavior.

<b>Suggested Workaround</b>
BIOS should set MSR C001_1023h[23].

<b>Fix Planned</b>
Yes</i></ul><a name="erratum319"></a>Und last but not least scheint der Phenom an einem <a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=321677">ähnlichen Problem</A> zu leiden wie die 65 nm K8-Prozessoren auf Brisbane-Basis. Auch hier liefern die internen Dioden "inkonsistente" Werte, sodass AMD empfiehlt sie nicht zu nutzen:<ul><i><b>319 Inaccurate Temperature Measurement</b>

<b>Description</b>
The internal thermal sensor used for CurTmp (F3xA4[31:21]), hardware thermal control (HTC), software thermal control (STC), and the sideband temperature sensor interface (SB-TSI) may report inconsistent values.

<b>Potential Effect on System</b>
HTC, STC and SB-TSI do not provide reliable thermal protection. This does not affect THERMTRIP.

<b>Suggested Workaround</b>
None. Systems should be designed with conventional thermal control and throttling methods or utilize PROCHOT_L functionality based on temperature measurements from an analog thermal diode (THERMDA/THERMDC). Systems should not rely on the HTC features, STC features or use SB-TSI. Software should not modify HtcTmpLmt (F3x64[22:16]) or enable any of the STC features by setting StcPstateEn, StcApcTmpLoEn, StcApcTmpHiEn, StcSbcTmpLoEn, or StcSpcTmpHiEn (F3x68[5,3:0]).

<b>Fix Planned</b>
Yes</i></ul>Danke Denniss für den Hinweis.

<b>Links zum Thema:</b><ul><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=326608">AMD Phenom Review</A></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1202862699">Phenom Stabilitätsprobleme aufgrund zahlreicher Ursachen</A></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1197028592">Korrektur zur TLB-Erratum 298 Berichterstattung</A></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1200995710">AMD Phenom ohne TLB-Fix - so geht's</A></li><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=326608">AMD Phenom Review</a></li><li><a TARGET="_blank" href="http://www.planet3dnow.de/cgi-bin/partner_preistrend/p3dclicks.pl?suchen.php?q=phenom+9500&s=0&a=&z=&x=0&y=0">AMD Phenom 9500 Preisvergleich</a></li><li><a TARGET="_blank" href="http://www.planet3dnow.de/cgi-bin/partner_preistrend/p3dclicks.pl?suchen.php?q=phenom+9600&s=0&a=&z=&x=0&y=0">AMD Phenom 9600 Preisvergleich</a></li><li><a TARGET="_blank" href="http://www.planet3dnow.de/cgi-bin/partner_preistrend/p3dclicks.pl?suchen.php?q=phenom+9600+black&s=0&a=&z=&x=0&y=0">AMD Phenom 9600 "Black Edition" Preisvergleich</a></li></ul>
 
Schöne Meldung ... aber wo ist da im PDF:

"41322 Rev. 3.00 September 2007 Revision Guide for AMD Family 10h Processors" da die Rede vom Errata 298?

MFG Bobo(2008 )
 
Leer mal Deinen Browsercache ;) Der in der Meldung verlinkte Revision-Guide ist vom Februar 2008, trägt aber den gleichen Dateinamen wie die alte Version vom September 2007.
 
Ich schätze deine Schnelligkeit Nero24 ... aber auch nach Leeren vom Browsercache bekomme ich immer noch dieses alte PDF bei AMD *noahnung*

MFG Bobo(2008 )
 
</ul>Und last but not least scheint der Phenom an einem <a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=321677">ähnlichen Problem</A> zu leiden wie die 65 nm K8-Prozessoren auf Brisbane-Basis. Auch hier liefern die internen Dioden "inkonsistente" Werte, sodass AMD empfiehlt sie nicht zu nutzen:<ul><i><b>319 Inaccurate Temperature Measurement</b>

<b>Description</b>
The internal thermal sensor used for CurTmp (F3xA4[31:21]), hardware thermal control (HTC), software thermal control (STC), and the sideband temperature sensor interface (SB-TSI) may report inconsistent values.

<b>Potential Effect on System</b>
HTC, STC and SB-TSI do not provide reliable thermal protection. This does not affect THERMTRIP.

<b>Suggested Workaround</b>
None. Systems should be designed with conventional thermal control and throttling methods or utilize PROCHOT_L functionality based on temperature measurements from an analog thermal diode (THERMDA/THERMDC). Systems should not rely on the HTC features, STC features or use SB-TSI. Software should not modify HtcTmpLmt (F3x64[22:16]) or enable any of the STC features by setting StcPstateEn, StcApcTmpLoEn, StcApcTmpHiEn, StcSbcTmpLoEn, or StcSpcTmpHiEn (F3x68[5,3:0]).
Na dann hoffen wir mal, dass das wenigstens bei Griffin anders ist. in mobile stromsparprozessor ohne funktionierende Temp Diode wäre nicht gerade der Hit.

Edit:
Ich bekomm auch nur die alte pdf, da hat AMD wohl Mist gebaut. Das Revision guide vom der alten Opteron Generation ist dagegen das Neue:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/33610.pdf

Da gibts auch einen neuen Bug, ist aber anscheinend uninteressant, nichts geplant etwas dagegen zu unternehmen.

ciao

Alex
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Ich hab die aktuelle PDF-Version mal angehängt. Funktioniert die jetzt bei Euch? *kopfkratz

Das Erratum 298 befindet sich auf Seite 39.
 
Aber da ist kein Errata 298 aufgelistet, obgleich das eine wirklich neue K8-Auflistung ist ... also da kommen mir noch weitere Zweifel bei AMDs Qualitätssicherung hoch ...
Ne das passt doch, das sind doch nur die alten K8, Rev.F Opterons, da gibts doch keinen L3, geschweige denn einen Bug damit ;-)

@Nero:
Danke fürs Hochladen, jetzt seh ich da "Februar 2008 Revision 3.16" auf der Titelseite ;-)

ciao

Alex
 
Damit fällt die Beschreibung des Erratum 298 leider nicht sehr viel ausführlicher aus,...
Zwar fällt die Beschreibung nicht ausführlich aus, aber im üblichen Rahmen eines Revision Guides oder Specification Updates. Selbst bei Intel, welche für gewöhnlich Wert auf eine ausgiebige und vorbildliche Dokumentation legen, sind die Beschreibung der Errata eher knapp gehalten. Jedenfalls die öffentlich zugänglichen. Ich denke wenn man eine NDA Verpflichtung unterzeichnet, werden die Mainboardhersteller und sonstige Geschäftspartner sowohl von Intel als auch von AMD ausführlichere Beschreibungen erhalten.
 
Zwar fällt die Beschreibung nicht ausführlich aus, aber im üblichen Rahmen eines Revision Guides oder Specification Updates. Selbst bei Intel, welche für gewöhnlich Wert auf eine ausgiebige und vorbildliche Dokumentation legen, sind die Beschreibung der Errata eher knapp gehalten. Jedenfalls die öffentlich zugänglichen. Ich denke wenn man eine NDA Verpflichtung unterzeichnet, werden die Mainboardhersteller und sonstige Geschäftspartner sowohl von Intel als auch von AMD ausführlichere Beschreibungen erhalten.

Das stimmt. Allerdings äußert sich Intel recht konkret bei jedem Fehler, ob er "in the wild" schon mal gesehen wurde. Bei AMD geht das wohl nur indirekt, bei Erratum 315 steht: "This sequence has not been observed in any production software." Wenn das nicht so da steht, kann man wohl davon ausgehen, dass der Fehler mit real existierender Software auch auftritt......

Problem bei AMD war eher, dass sie so einen Wind drum gemacht haben, gestandenen Computerexperten beim Warschauer Benchfest auch noch die Geschichte mit dem 9700 aufgetischt haben, erzählt haben, der Mitarbeiter, der die Revision-Guides herausbringt, gerade im Urlaub sei und sich zur Praxisrelevanz eben trotz der vielen Aufregung nicht äußern möchten......Von Krisenmanagement war da irgendwie wenig zu sehen, das war eben eher Hühnerhaufen.

Wenn denn die Spider-Platform wenigstens bei jedem rock-stable wäre, hätten sich die Leute vielleicht auch schneller wieder beruhigt. Aber es gibt ja genug Leute, bei denen das nicht so ist (einschließlich einiger Warschauer Systeme, bereitgestellt von AMD selber......), was natürlich zusätzliche Unruhe produziert.
 
Zuletzt bearbeitet:
Sehen wir das doch mal von der "heiteren" Seite ...

Offenbar kann man bei AMD auch in dieser krisengeschüttelten Zeit 3 Monate Urlaub bekommen ... *chatt*
 
Ergänzung: Wobei ich gerade bei erratum 315 bin. Auch wenn angeblich nie in the wild gesehen, könnte das nicht ein Fehler sein, der gelegentlich mal Vista-64-Probleme bereiten könnte? Gibt ja so die Theorie, dass der Phenom sich damit manchmal schwer tut......
 
An die Profis:

"BIOS should set MSR C001_0015h[3] (HWCR[TlbCacheDis]) to 1b and MSR C001_1023h[1] to 1b."

Wie kommt man über "C001_0015h[3] to 1b" von 01000010 (TLB-Fix inaktiv) auf 01000018 (TLB-Fix aktiv)? Mir scheint mit Index [3] ist das letzte 2er Zahlenpaar gemeint. Aber wie komme ich mit 1b auf die Ziffern 18?

Der Singu
 
Zuletzt bearbeitet:
Ich würde mal tippen, es bedeutet Bit 3. 2^3 ist 8, daher der Sprung von 0 auf 8 an der letzten Stelle.
 
Der Revision-Guide für die DDR1-Generation wurde übrigens auch aktualisiert, damit hätt ich ja nicht mehr gerechnet.....
 
Das stimmt. Allerdings äußert sich Intel recht konkret bei jedem Fehler, ob er "in the wild" schon mal gesehen wurde. Bei AMD geht das wohl nur indirekt, bei Erratum 315 steht: "This sequence has not been observed in any production software." Wenn das nicht so da steht, kann man wohl davon ausgehen, dass der Fehler mit real existierender Software auch auftritt......
Da wäre ich mir nicht so sicher.

http://www.planet3dnow.de/vbulletin/showthread.php?t=331919
Interessant ist aber allemal, dass Tommy Minyard vom Texas Advanced Computing Center (TACC) beim mit fast 16.000 Quad-Core Opteron Prozessoren ausgestatteten Supercomputer "Ranger" (wir berichteten) Datenkorruptionen beobachtet hat, die durch den von AMD entwickelten Kernel-Patch dann behoben wurden.
 
Zwar fällt die Beschreibung nicht ausführlich aus, aber im üblichen Rahmen eines Revision Guides oder Specification Updates. Selbst bei Intel, welche für gewöhnlich Wert auf eine ausgiebige und vorbildliche Dokumentation legen, sind die Beschreibung der Errata eher knapp gehalten. Jedenfalls die öffentlich zugänglichen. Ich denke wenn man eine NDA Verpflichtung unterzeichnet, werden die Mainboardhersteller und sonstige Geschäftspartner sowohl von Intel als auch von AMD ausführlichere Beschreibungen erhalten.


Mmmhh, mal angenommen, Deine Vermutung des NDAs stimme, warum dann eine Geheimniskrämerei um einen Fehler machen? Mir fallen da spontan einige Dinge ein, zum Beispiel böswillige Ausnutzung eines Fehlers durch Dritte (um Spionage betreiben zu können oder um einfach Rechner unbrauchbar zu machen). Aber eine 'Öffnung' würde hier wie im OpenSource Bereich gewiß wesentlich schneller zu einer Schutzmaßnahme führen - im schlimmsten Falle eben durch Vermeidung der Bug-behafteten CPU. Aber wenn Letzteres der Fall wäre, würde ein Hersteller bewußt ein defektes Produkt in Umlauf bringen. Und ob das dann rechtlich keine Konsequenzen hätte, weiß ich nicht so recht zu beantworten. Die letzte mir einfallende Möglichkeit wäre: man kann durch eine detaillierte Beschreibung eines Fehlers Rückschlüsse auf die Konstruktion und Arbeitsweise eines Prozessors schließen. Könnte das dann dazu führen, daß NDAs abgeschlossen werden?

Der TLB Bug in AMDs K10 ist mir äußerst suspekt! Warum druckst AMD so lange um die Dokumentation dessen herum? Und nun finden wir eine 'Beschreibung', die im grunde genau dem entspricht, was seit Monaten in der Presse kursiert. Hat AMD vielleicht einfach nur abgewartet und genau das ins Erratum geschrieben, was eh längst aus unsicheren Quellen in Umlauf geraten ist? Ich meine, was würde uns davon abhalten es als wahr zu halten, wo es doch jeder ganz offenbar zu wissen glaubt? Eigenartig, eigenartig. Irgendwie beschleicht mich das Gefühl, daß AMD nicht ganz Intels 'C2D-Schlag verpennt hat und zu spät einen Leistungshemmer im K10-Design entdeckt hat, dessen Problematik viel tiefliegender ist als zugegeben wird. Das gehört natürlich ins Reich der Gerüchte, aber welches Unternehmen kann es sich denn leisten eine so schlechte Performance wirtschaftlich an den Tag zu legen und den Aktienkurs ins bodenlose abrutschen zu lassen? Aber gemäß des Ockhamschen Prinzipes ist es die einfache Lösung, die die richtige ist: AMD ist einer großen Fehlentscheidung zum Opfer geworden ...
.
EDIT :
.

Sehen wir das doch mal von der "heiteren" Seite ...

Offenbar kann man bei AMD auch in dieser krisengeschüttelten Zeit 3 Monate Urlaub bekommen ... *chatt*


... heißt dann 'Zwangsurlaub' ... wo? In der Karibik auf Kosten der deutschen Sozialhilfe?
 
Da wäre ich mir nicht so sicher.

Lies noch mal meinen post....;) Ich habe nichts anderes geschrieben, als dass vermutlich Erratum 298 mit normaler Software auftauchen kann, Erratum 315 dagegen offenbar laut AMD nicht......

Wobei das von dir zitierte insofern auch wirklich interessant ist, weil ein number-cruncher wohl in aller Regel sich nicht mit Virtualisierung rumschlagen wird, das kostet nur unnötig Leistung IMHO. Also entkräften solche Aussagen zumindest das Märchen, der TLB-Bug tritt nur in virtuellen Umgebungen auf.
 
Lies noch mal meinen post....;) Ich habe nichts anderes geschrieben, als dass vermutlich Erratum 298 mit normaler Software auftauchen kann, Erratum 315 dagegen offenbar laut AMD nicht......

Wobei das von dir zitierte insofern auch wirklich interessant ist, weil ein number-cruncher wohl in aller Regel sich nicht mit Virtualisierung rumschlagen wird, das kostet nur unnötig Leistung IMHO. Also entkräften solche Aussagen zumindest das Märchen, der TLB-Bug tritt nur in virtuellen Umgebungen auf.
Hast recht, hab mich verlesen. ;)
 
Zurück
Oben Unten