Linux Kernel Patch für TLB-Erratum 298

In einer Mailing Liste auf x86-64.org hat AMD weitere detaillierte Informationen zum TLB-Erratum 298 veröffentlicht und bietet auch einen Kernel Patch an.

<ul>"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.
The system may experience a machine check event reporting an L3 protocol error has occurred. In this case, 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."</ul>
Mit dem Kernel Patch können die Performanceeinbußen durch die geplanten Workarounds mittels BIOS-Updates verhindert werden. Ein <a href="https://www.x86-64.org/pipermail/discuss/2007-December/010260.html" target="B">64-Bit Patch</a> existiert bereits für den Kernel 2.6.23.8. AMD empfiehlt diesen Patch allerdings nur Usern, die durch den Bug wirklich betroffen sind.

<b>Quelle:</b> <a href="https://www.x86-64.org/pipermail/discuss/2007-December/010259.html" target="b">AMD Family 10h revision B2 Erratum 298 and L2 Eviction Bug Workaround</a>

<b>Links zum Thema:</b><ul><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1196811435">TLB-Erratum, Phenom 9550 und 9650 für B3-Stepping</a></li><li><a href="http://techreport.com/discussions.x/13724" TARGET="_blank">Erratum degrades Phenom 9500, 9600 performance [The Tech Report]</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1196765848">AMD Phenom 9700 und 9900 ab Anfang Februar?</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1195410896">AMD zieht 2,4 GHz Phenoms zurück</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1195467153">Phenom Vorstellung</a></li><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=325750">Ausführliches AMD Phenom Reviews</a></li><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=321677">AMDs G2-Stepping: das letzte Aufbäumen des K8-Kerns</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/partner_preistrend/p3dclicks.pl?AMD_AMD_Phenom_Preisvergleich__x73077E0307757A07764D06.html" TARGET="_blank">AMD Phenom Preisvergleich</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/partner_preistrend/p3dclicks.pl?AMD_Athlon_64_Preisvergleich__x73077E0307757307764D06.html" TARGET="_blank">AMD Athlon 64 Preisvergleich</a></li></ul>

Ich dachte alle sind betroffen?

Muku-Muku schrieb:

Ich dachte alle sind betroffen?

Zum Vergrößern anklicken....

Betroffen im Sinne von "der Bug macht sich bemerkbar". Er soll ja nur bei ganz bestimmten Konstellationen äußern.

Und woher weiß ich 100%, dass der Bug mich nie betreffen wird?

Muku-Muku schrieb:

Und woher weiß ich 100%, dass der Bug mich nie betreffen wird?

Zum Vergrößern anklicken....

Wenn Dein Rechnen nicht hängen bleibt während alle Cores ausgelastet sind, dann bist Du auf der sicheren Seite.

lg
__tom

Nicht ganz. Schließlich muss dann auch der TLB tatsächlich auf eine ganz bestimmte Art und Weise genutzt werden. Der Fehler ist kaum reproduzierbar und gerade für Server ist so etwas tödlich. Nicht ohne Grund rät AMD auch dringend zu einem BIOS-Update.

Patmaniac schrieb:

Nicht ganz. Schließlich muss dann auch der TLB tatsächlich auf eine ganz bestimmte Art und Weise genutzt werden. Der Fehler ist kaum reproduzierbar und gerade für Server ist so etwas tödlich. Nicht ohne Grund rät AMD auch dringend zu einem BIOS-Update.

Zum Vergrößern anklicken....

Phenom und Server ?
Hm, Ich dachte immer dass die Barcelonas für Server sind und alle CPUs unterhalb von 2,4GHz das Problem nicht haben, bzw dass das erratum dort nicht zu tragen kommt.

Aber im Panik-Modus von etlichen Leuten ist es bald so, dass wahrscheinlich die K8 CPU's auch von diesem Problem erfasst werden

lg
__tom

tomturbo schrieb:

Hm, Ich dachte immer dass die Barcelonas für Server sind und alle CPUs unterhalb von 2,4GHz das Problem nicht haben, bzw dass das erratum dort nicht zu tragen kommt.

Zum Vergrößern anklicken....

Das ist eine veraltete Info. Lies mal die gestrige Meldung dazu
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1196811435

Laut Michael Saucier, Desktop Product Marketing Manager bei AMD, kann dieser Bug bei jeder Taktfrequenz auftreten. Er widerspricht damit der ursprünglichen AMD-Sprachregelung, wonach Phenoms erst ab 2.4 GHz davon betroffen wären.

Zum Vergrößern anklicken....

Hab' ich Nero24 hab' ich, aber ganz ehrlich von technischen Aussagen eines Marketing Managers ist wieviel zu halten??

lg
__tom

Wenn sie sich gegen die eigene Firma wenden viel...

tomturbo schrieb:

Hab' ich Nero24 hab' ich, aber ganz ehrlich von technischen Aussagen eines Marketing Managers ist wieviel zu halten??

Zum Vergrößern anklicken....

Man darf Sie zumindest kritisch betrachten.

Vielleicht noch die Zusatzinfo, wie der Fehler umgangen wird:

The basis for the kernel patch solution depends on the root cause of
the L2 eviction problem. The only exposure for the problem is when
the TLB needs to set an A or D bit in a page table entry. If the TLB
never needs to set an A or D bit, the bug cannot occur. By emulating
the A and D bits with the help of the Present and Writable bits, the
patch will ensure the real A and D bits are always preset. It works
by forcing a page fault when the first access is made to a page with
the emulated A bit not set, and when the first write access is made
to a writable page with the emulated D bit not set. Emulated A and D
bits are stored in bits generally available to the OS in the page
table entry.

Zum Vergrößern anklicken....

Wenn ich das richtig verstehe sind also 2 Bits der Übeltäter, die flickschustermäßig über 2 andre Bits ersetzt/emuliert werden..

ciao

Alex

Hey das ist doch mal endlich eine schnelle Reaktion Seitens AMD.

Problem => Patch und auch noch für tux.

uncle_sam schrieb:

Hey das ist doch mal endlich eine schnelle Reaktion Seitens AMD.

Problem => Patch und auch noch für tux.

Zum Vergrößern anklicken....

Als ob AMd den Patch programmiert hätte. Das zeigt nur mal wieder den Enthusiasmus der freien Programmierer. Ok ich gebs zu, ich habs überlesen und behaupte nun das Gegenteil. Dickes Lob an AMDs fleißige Linux-Programmierer. Die x86-64.org Links gehen bei mir nicht. Für Windows könnte sich das hinziehen, wenn Microsoft den Patch dort auch in den Kernel einarbeiten muss. Offenbar kann man das ja nicht über ein simples MicroCode-Update beheben, für mich heißt das, dass der Fehler in eine kritische Kategorie fällt.

genervt schrieb:

Als ob AMd den Patch programmiert hätte. Das zeigt nur mal wieder den Enthusiasmus der freien Programmierer. Für Windows könnte sich das hinziehen, wenn Microsoft den Patch dort auch in den Kernel einarbeiten muss. Offenbar kann man das ja nicht über ein simples MicroCode-Update beheben, für mich heisst das, dass der Fehler in eine kritische Kategorie fällt.

Zum Vergrößern anklicken....

Oh man, du solltest wirklich mal auch das lesen was da steht!

A Linux 64-bit patch was developed for 2.6.23.8 by AMD's OSRC team and will be
posted to this list by Joerg Roedel.

Zum Vergrößern anklicken....

Der Patch wurde gepostet von einer email adresse mit dem Zusatz "amd.com".

Es ist nicht so, dass der Patch von der Community erstellt wurde. Der Patch kommt von AMD,
genauso wie der powernow-k7, -k8 etc. Treiber.
Es ist nicht so, dass nur freie Entwickler am Linux Kernel arbeiten, im Gegenteil, die meisten
sind sogar bei Sun, Google o.ä. eingestellt.


Interessant wäre hier mal ein Performancevergleich mit und ohne Patch.
@kiri: Your turn.
.
EDIT :
.

Nero24 schrieb:

Das ist eine veraltete Info. Lies mal die gestrige Meldung dazu
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1196811435

Zum Vergrößern anklicken....

Nicht unbedingt bedeutet das, dass die Opterons davon betroffen sind.
Die Opterons haben ja ein anderes Stepping als die Phenoms und deshalb könnte es doch
durchaus sein, dass die den Fehler nicht aufweisen.

Berniyh schrieb:

Nicht unbedingt bedeutet das, dass die Opterons davon betroffen sind.
Die Opterons haben ja ein anderes Stepping als die Phenoms und deshalb könnte es doch
durchaus sein, dass die den Fehler nicht aufweisen.

Zum Vergrößern anklicken....

Doch, der Barcelona hat auch das B2-Stepping! Es sind bis zum B3-Stepping alle K10 betroffen.

Patmaniac schrieb:

Doch, der Barcelona hat auch das B2-Stepping! Es sind bis zum B3-Stepping alle K10 betroffen.

Zum Vergrößern anklicken....

War der nicht BA Stepping? (Laut Wiki de/en und meiner Erinnerung.)
Das war doch gerade der Grund, dass der Phenom später kam, wegen des B2 Steppings.

Man kann jetzt natürlich das aus der anderen Meldung so interpretieren, dass der Fehler
auch beim Opteron auftritt (das mit dem Auslieferungsstopp).
Ich wollte nur sagen, dass ich finde, dass Nero da ein bissle arg schnell Rückschlüsse
gezogen hat, ich sollte nicht sagen, dass diese falsch sind.
.
EDIT :
.
Laut Heise hat wohl AMD auch Barcelonas des B2 Steppings verkauft und diese werden
nun gestoppt.
http://www.heise.de/newsticker/meldung/100165

Linux rettet AMD mal wieder den Arsch. Durch den Patch kann sich AMD einigermassen rehabilitieren und den Druck auf Microsoft schieben, schleunigst Windows zu patchen.

Auch bei der Opteron-Einführung hätten sie damals ohne Linux 64bit doch sehr alt ausgesehen und hätten die großen Performance-Steigerungen bei mancher Software, die Ihre Arbeit nur in 64 bit in einem statt 4 CPU-Takten erledigt, gar nicht vorführen können.

Als Dank gibt es einen open source Grafiktreiber ohne UVD Support und weiterhin einen closed source Treiber statt alle Ressourcen zu bündeln.

Schugy schrieb:

Als Dank gibt es einen open source Grafiktreiber ohne UVD Support und weiterhin einen closed source Treiber statt alle Ressourcen zu bündeln.

Zum Vergrößern anklicken....

Was soll denn der eine Windows Entwickler, der monatlich für einen Tag abgestellt wird,
groß bei der Entwicklung des Open Source Treibers helfen?

Ok, jetzt mal ernst. Ich finde es nicht wirklich schlimm, dass der Closed Source Treiber
weiter existiert. Zumindest, bis der radeonhd Treiber und der radeon Treiber weitgehend
featurekomplett sind sollte man den Closed Source schon weiterentwickeln. Wenn AMD nun
wirklich alle Ressourcen auf den radeonhd Treiber werfen würde, dann würde es wohl dennoch
nicht so schnell gehen, dass man den Closed Source fallen lassen kann und da der Treiber
in dem Zustand wie er vor einem halben Jahr etwa war (und auch immer noch zumindest
teilweise ist), schon am Image kratzt macht AMD mittelfristig hier alles richtig.
Ob man den Treiber langfristig weiterentwickelt muss man halt mal sehen.

Zu UVD:
Es wurde ja schon gesagt, dass man versucht so viel wie möglich davon zu veröffentlichen,
wenn also Teile davon veröffentlicht werden können, ohne gegen die Rechte anderer zu
verstoßen, dann wird das gemacht, so John Bridgman im Phoronix Forum.
Das Problem ist halt nun mal, dass AMD sich bezüglich der Kopierschutzsysteme dazu
verpflichtet die Spezifikationen derer geheimzuhalten.
Davon kann man halten was man will, aber es ist nun mal so und deswegen kann man
AMD hier keinen Vorwurf machen.
Der Einwand, der immer wieder im Phoronix Forum gebracht wird, dass diese Systeme
ohnehin nutzlos seien zählt nicht, denn AMD kann ja dennoch nicht einfach die Specs
dazu rausrücken, ohne gegen bestehende Auflagen und Verträge zu verstoßen.

Na dann warten wir mal, bis die Treiber zumindest unverschlüsselte Videos beschleunigen und die Bildqualität verbessern. Allerdings ist mir noch unklar, wie ich jemals ein geschützten Hollywoodstreifen auf mener Linux-Kiste abspielen soll, ohne mir ein Rootkit unterjubeln zu lassen, das mit freier Software rein gar nichts zu tun hat.