Archiv verlassen und diese Seite im Standarddesign anzeigen : Intel - Intel Nehalem mit TLB-Bug
Hallo,
habe inzwischen auf mehreren Seiten gelesen, dass auch Intels Nehalem einen Bug in der TLB-Einheit hätte.
Wie schwerwiegend schätzt ihr den Fehler ein? Hier ein paar Links:
http://www.fudzilla.com/index.php?option=com_content&task=view&id=10707&Itemid=1
http://download.intel.com/design/processor/specupdt/320836.pdf
http://www.hardware-infos.com/news.php?news=2553
Avalox
2008-12-01, 13:39:34
Hallo,
habe inzwischen auf mehreren Seiten gelesen, dass auch Intels Nehalem einen Bug in der TLB-Einheit hätte.
Wie schwerwiegend schätzt ihr den Fehler ein? Hier ein paar Links:
Die Auswirkung kann auf jeden Fall sehr kritisch sein. Nun steht dort scheinbar nicht in den Info, wann der Fehler tatsächlich auftritt. Deshalb kann man auch nicht mutmaßen, wie dieser durch ein Bios zu umschiffen ist.
Das Umschiffen unter Windows, war ja der Supergau für den alten Phenom. Nun traue ich aber MS zudem mehr Einfluss auf MS zu, als es ein AMD hätte tun können.
Ist aber schon lustig.
user77
2008-12-01, 13:40:54
gilt das auch für die Xeon Prozessoren?
Avalox
2008-12-01, 13:43:06
gilt das auch für die Xeon Prozessoren?
Die gibt es ja noch nicht.
Ja, wahrscheinlich. War zumindest bei AMD auch so, dass Desktop und Server betroffen waren. Meistens kommen die ja aus einem Guss.
Ja, wahrscheinlich. War zumindest bei AMD auch so, dass Desktop und Server betroffen waren. Meistens kommen die ja aus einem Guss.
Ne, i7 Xeons gibts noch nicht. Bis die nächstes Jahr rauskommen hat Intel 100% eine neue Revision fertig, so wie AMD die B3 Rev. nachgeschoben hat.
ciao
Alex
reunion
2008-12-01, 14:31:25
Das erklärt dann auch warum Intel zuerst den Desktopmarkt bedient. Das ist unter normalen Umständen alles andere als üblich.
Matrix316
2008-12-01, 14:37:27
Jetzt kopiert Intel schon die Bugs von AMD. :ugly:
Wobei der Rechen Bug damals dem Pentium auch nicht sooooo geschadet hat.
SavageX
2008-12-01, 14:52:49
Na, jede Architektur hat so ein paar Macken. Praktisch jeder Prozessor lässt sich unter Randbedingungen dazu verleiten, sich komplett zu verzetteln - die Designs sind halt komplex.
"We were told that Intel's Nehalem, the CPU that we know as Core i7 has TLB."
Errr... Schock? Ein TLB ist Standard und absolut notwendig?! (Hier fehlt wohl einfach das Wort "bug". Fuad sollte die Artikel mal durchlesen lassen bevor er sie online stellt.)
Spasstiger
2008-12-01, 15:00:10
"We were told that Intel's Nehalem, the CPU that we know as Core i7 has TLB."
Wenigstens hat er kein AIDS. ;)
AnarchX
2008-12-01, 15:03:04
Dass wird wohl eher der TLB-Bug sein, denn schon Core 2 hatte:
http://en.wikipedia.org/wiki/Intel_Core_2#Chip_bugs
... der offenbar damit zusammenhängt, dass unter x86 keine wirkliche Spezfikation für den TLB gibt und somit manche SW-Implementierung die auf einer älteren CPU basiert eben Probleme machen kann.
Beim K10 hingegen war ja wohl eher das Problem, dass hier am TLB wirklich etwas defekt war und es auch bei korrekten Implementierungen zu Fehlern kam.
Aber diesmal will man offenbar ein Bios-Update liefern. Weil's so schlimm ist oder weil man einfach nett sein will? ;)
Exxtreme
2008-12-01, 15:23:56
Hoffentlich wird das ein BIOs-Update beheben ohne auf die AMD-Hammermethode (TLB komplett abschalten) zurückzugreifen. Denn diese kostet extrem viel Leistung.
MadManniMan
2008-12-01, 15:37:46
So schade das für die Performanceentwicklung doch wäre - immerhin hätte AMD somit eine kleine Chance, wieder ein wenig aufzuschließen.
Wer weiß: vielleicht holt AMD durch Intels TLB-Bug wieder auf, was man durch den eigenen verlor?
Avalox
2008-12-01, 15:38:08
Hoffentlich wird das ein BIOs-Update beheben ohne auf die AMD-Hammermethode (TLB komplett abschalten) zurückzugreifen. Denn diese kostet extrem viel Leistung.
Die "AMD Lösung" wurde im Vorfeld auch als Bios Lösung bezeichnet. Was sie ja auch ist, mehr oder weniger.
Stellt schon eine Extremsituation dar. Glaube nicht, der Zufall wäre ja zu gross und Intel hätte doch solch einen Prozessor niemals in den Verkauf gegeben.
Wenn es schon so schlimm kommt, dann glaube ich eher an ein Windows Update. Hätte es für AMD ja niemals gegeben, obwohl natürlich damals auch dieses möglich gewesen wäre.
Exxtreme
2008-12-01, 15:52:12
Problem an solchen Bugs ist, man kann sie nicht wirklich reproduzieren. Selbst die bei heise haben sich da die Zähne ausgebissen beim Phenom. Kann gut sein, daß die Chose jahrelang problemlos läuft, plötzlich Bluescreen/Kernel panic. Nach dme Neustart ist dann alles wieder heile.
reunion
2008-12-01, 16:02:51
Dass wird wohl eher der TLB-Bug sein, denn schon Core 2 hatte:
http://en.wikipedia.org/wiki/Intel_Core_2#Chip_bugs
... der offenbar damit zusammenhängt, dass unter x86 keine wirkliche Spezfikation für den TLB gibt und somit manche SW-Implementierung die auf einer älteren CPU basiert eben Probleme machen kann.
Beim K10 hingegen war ja wohl eher das Problem, dass hier am TLB wirklich etwas defekt war und es auch bei korrekten Implementierungen zu Fehlern kam.
Irgendetwas ist bei Nehalem jedenfalls faul da man ihn bisher nur für den Desktop bringt. Gerade Nehalem, der auf das Serversegment zugeschnitten wurde, und endlich die Missstände behebt, die AMD seit mehreren Jahren dank des integrierten MCs und HTT eine ausgezeichnete Position im Seversegment garantieren, kommt irgendwann 2009 für Server und jetzt schon für den Desktop? Gerade wo die Stückzahlen nirgends sonst so niedrig und die Margen so hoch sind wie im Serversegment? - Was dieses eigentlich für die Einführung einer neuen Architektur prädestiniert. Das stinkt doch zum Himmel!
Das Problem tritt nur auf wenn Systemsoftware, also das BIOS oder Ring-0-Code den TLB falsch invalidiert. Es lässt sich mit korrektem Code im BIOS ohne weiteres beheben ohne Performanceverlust.
Es gibt genügend ähnlich "kritische" Fehler in Intel- und AMD-Prozessoren. Nur weil "TLB" im Namen ist wie bei Phenom muss man noch lange nicht einen solchen Rummel drum machen.
Ich zitiere mal Seite 27 aus dem Dokument. Hier heißt es nicht "in rare instances", sondern "certain".
"Under certain conditions when C6 and two logical processors on the same core are enabled on a processor, an instruction fetch occurring after a logical processor exits from C6 may incorrectly use the translation lookaside buffer (TLB) address mapping belonging to the other logical processor in the processor core."
Glaube nicht, dass es sich um einen solchen Bug wie seinerzeit beim Phenom handelt, aber es ist auch schon mehr dran, als der ein oder andere im Thread versucht, die Lage runterzukochen.
Nein, es ist nicht mehr dran. Der Exit von C6 kann nur in Systemsoftware auftreten. Das heißt es passiert auf derzeitigen Betriebssystemen entweder überhaupt nicht oder es ist einfach fixbar. Wahrscheinlich sogar durch Microcode.
Der TLB-Fehler des Phenom war von ganz anderer Tragweite.
Wo liest du im von mir verlinkten Zitat etwas von Systemsoftware?
Das erklärt dann auch warum Intel zuerst den Desktopmarkt bedient. Das ist unter normalen Umständen alles andere als üblich.
Ist ja logisch, da man da den TLB-Bug wohl nicht merken wird, bei Servern ist das schon was anderes ;)
Wo liest du im von mir verlinkten Zitat etwas von Systemsoftware?
Umstellung der C-States ist immer Ring-0-Code.
Vor allem kann eine "TLB Invalidation" auch überhaupt nicht von User-Space-Software veranlasst werden.
mAxmUrdErEr
2008-12-01, 17:48:54
Spannend, wie manche sofort in Panik verfallen und "ICH HABS SCHON IMMER GEWUSST LOL!!!111" schreien, obwohl sie offensichtlich keine Ahnung haben wann der Bug auftritt und was er bewirkt.
Danke an Coda für die Aufklärung, jetzt können alle wieder schlafen gehen. :)
BlackBirdSR
2008-12-01, 17:51:43
Ich zitiere mal Seite 27 aus dem Dokument. Hier heißt es nicht "in rare instances", sondern "certain".
und "certain" heisst nichts anderes, als unter ganz speziellen Bedingungen.
Sorkalm
2008-12-01, 18:06:13
rare heißt selten / speziell, certain doch bestimmten. Gerade bei letzteren kann man es also näher eingrenzen ... nur warum macht Intel das dann nicht?
BlackBirdSR
2008-12-01, 18:17:20
rare heißt selten / speziell, certain doch bestimmten. Gerade bei letzteren kann man es also näher eingrenzen ... nur warum macht Intel das dann nicht?
Würdest du das tun, wenn du nicht 100% sicher gehen kannst, dass das Problem nicht größer werden könnte? Im unwahrscheinlichen Fall, dass jemand einen Exploit finden könnte, der damit ne Menge Corei7 Systeme lahm legt oder ausbremst, wäre das eben ein "certain case" und kein "rare instance" ;)
dildo4u
2008-12-01, 18:37:16
Kann es sein das es zur "Sicherheit" in allen Docs vermerkt wird?Laut Intel hatte jede Core 2 Serie den Bug egal welches Modell/Revision.
http://www.xtremesystems.org/forums/showpost.php?p=3466632&postcount=46
Sorkalm
2008-12-01, 18:45:54
Das ist nur der eine, ältere Erratum. Die neuen haben die alten Core 2s genauso wenig, wie SMT, das wie auch C6 damit im Zusammenhang stehen zu scheint...
Mal sehen ob Intel auch ordentlich einen aufm Deckel bekommt wie AMD damals.
Mal sehen ob Intel auch ordentlich einen aufm Deckel bekommt wie AMD damals.
Nein, weil der Fix keinen Einfluss auf die Performance hat. Zudem ist das Problem ein völlig anderes.
VooDoo7mx
2008-12-02, 05:28:50
Dieses Errata wird bei Intel schon seit der P6 (PentiumPro) Architektur geführt, also schon über 10 Jahre lang.
Aber wenn es so Idioten wie Fudo ausgraben ist es natürlich superneu und ultrawichtig und wird bis ins unendliche aufgeblasen.
Einfach lächerlich wie sich immer die selben Schwachsinnsseiten mit als Neuheit verkauften Bullshit profilieren wollen.
Fast noch lächerlicher hier sind die User hier die auf sowas noch anspringen.
Manchmal wünschte ich mir echt, dass Fudo von einen ganz großen LKW überfahren wird. Aber dann lieber doch nicht, warscheinlich tritt ein noch größerer Idiot an seine Stelle. :ugly:
BlackBirdSR
2008-12-02, 07:34:26
Manchmal wünschte ich mir echt, dass Fudo von einen ganz großen LKW überfahren wird. Aber dann lieber doch nicht, warscheinlich tritt ein noch größerer Idiot an seine Stelle. :ugly:
Na mal langsam mit diesen lebensfeindlichen Wünschen. Immerhin gibt es genug Situationen in denen wir froh waren, dass jemand etwas tiefer und unfreundlicher gebohrt hat. Dass Fudzilla dabei soetwas wie die Bild am Hardwaremarkt ist, sollte man wann imer zutreffend ausblenden können. Muss man halt etwas mitdenken, wenn man es bei Fuzilla schon nicht tut.
Hier die inzwischen offiziellen Dementis:
http://www.hardware-infos.com/news.php?news=2556
http://www.computerbase.de/news/hardware/prozessoren/intel/2008/dezember/tlb-bug_intel_core_i7_oder/
http://techreport.com/discussions.x/15979
Man darf aber Fuad auch nicht die Schuld so in die Schuhe schieben. Schließlich hat Intel auch eingeräumt, dass es ihr Fehler war, die Notiz weiter in der Dokumentation rumzuschleppen. Ich nehme an, dass sie sie demnächst korrigieren. ;)
w0mbat
2008-12-02, 22:08:31
Wieso Dementi? Der Core i7 hat einen TLB-Bug, der aber mit einem Bios-Update behoben wurde. Oder hat ein Pheom B2 mit Bios-Fix plötzlich keinen TLB-Bug mehr? Nein, er ist nur nicht mehr "aktiv".
w0mbat, wie wär's wenn du erstmal liest anstatt hier einen reinzustellen?
Die Situation ist in keinster Weise vergleichbar. Der Bug ist völlig anderer Natur, weitaus unkritischer und zudem ohne Performanceimplikationen fixbar.
Mich regt vor allem auf dass jetzt alle Erratas in denen nur das Wort "TLB" vorkommt auf einmal in einen Eimer geworfen werden. Das ist einfach nur lächerlich. Solche Bugs die von Systemsoftware vermieden werden müssen oder per Microcode-Update behoben werden vor dem Launch haben alle modernen CPUs.
w0mbat
2008-12-03, 13:34:26
Hat den Core i7 nun einen Bug in der Hardware der etwas mit dem TLB zu tun hat, ja oder nein? Wenn ja hat der Core i7 einen TLB-Bug.
BlackBirdSR
2008-12-03, 14:04:47
Hat den Core i7 nun einen Bug in der Hardware der etwas mit dem TLB zu tun hat, ja oder nein? Wenn ja hat der Core i7 einen TLB-Bug.
Hat jemand bestritten, dass i7 Fehler im Bereich des TLB hat? Nicht dass ich wüsste. Coda hat dich wegen etwas ganz anderem angesprochen.
Du solltest nämlich mal darauf achten welches Dementi hier gemeint ist. Intel dementiert, dass es sich um einen ähnlich (fatalen) Bug handelt, wie beim K10. Zudem sagt man, dass alle bekannten Errata bereits per Bios-Update und oder Microcode gefixt wurden.
Ich renne ja auch nicht rum und bestehe darauf, dass K5/6/7/8/10 einen FPU-Bug haben. Einige der Gatter funktionieren generell nicht so wie gewollt, dafür ist Microcode, Revision-Update oder Ignorieren als Lösung ja da.
w0mbat
2008-12-03, 15:18:32
Weil der Gast geschrieben hat es gäbe offizielle Dementis und ich ihm geglaubt habe.
BlackBirdSR
2008-12-03, 16:14:09
Weil der Gast geschrieben hat es gäbe offizielle Dementis und ich ihm geglaubt habe.
gibt es doch auch, siehe Links1
Man nimmt Stellung zu den aufkeimenden Gerpchten, es würde sich um einen ähnlich gravierende Bug wie beim Barcelona handeln.
w0mbat
2008-12-03, 17:55:04
Wenn jemand Dementi schreibt in nem Thread in dem es um einen TLB-Bug geht bezieht man dass eben auf den Bug. Logisch.
BlackBirdSR
2008-12-03, 21:03:22
Wenn jemand Dementi schreibt in nem Thread in dem es um einen TLB-Bug geht bezieht man dass eben auf den Bug. Logisch.
Genau, es gibt Probleme mit einigen Funktionen die den TLB betreffen. Laut Intel wurden diese vor Auslieferung behoben. Es soll auch keine spürbaren Performanceeinschnitte oder Stabilitätsprobleme geben.
Wenn Intel nicht lügt, ist die Sache damit geklärt. Prima.
Avalox
2008-12-07, 19:31:36
AS hat sich auch zum Bug gemeldet
Andreas Stiller c't PG S.18 26/2008
"Nehalem hat neben einigen weniger aufregenden Fehlern auch den Formalismus der korrekten Invalidierung des Translation Lookaside Buffer (TLB) geerbt. Der ist dann aufwendiger, wenn sogenannte Paging Structure Caches mit ins Spiel kommen. Bei Nehalem wird das zudem weiter verkompliziert, da er Expanded Page Tables (EPT) sowie zusätzlich ID-Einträge für Virtuelle Prozessoren (VPIDs) bietet. Diese Features können die Virtualisierung erheblich beschleunigen, nur sind dann auch die neuen Invalidierungsbefehle wie invvpid und invept zu benutzen. "
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.