Harlekin
PCGH-Community-Veteran(in)
Ja natürlich, Intel vertuscht die Tatsache, in dem sie den Fehler bereits vor Release in einem öffentlichen Dokument veröffentlichen...
PCGH.de: Auch Intels Core-i7-CPUs von TLB-Bug betroffen
- Ersteller PCGH-Redaktion
- Erstellt am
DaStash
PCGH-Community-Veteran(in)
Aber denkst du nicht auch das es ein ganz normales Verhalten von Unternehmen ist bestehende Probleme herunterzuspielen um eben nicht die Kundschaft und Geschäftspartner zu verprellen?
Von daher verstehe ich deinen Einwand und deine Kritik überhaupt nicht?!
Das ist doch das normalste der Welt, im Geschäftsleben, dass aus Kleinigkeiten keine Elefanten gemacht werden.
Von daher halte ich eher die Tatsache das du davon ausgehst das in der Geschäftswelt alle ehrlich miteinander umgehen für weltfremd/ realitätsfern. Was jetzt nicht bös gemeint sein soll
MfG
Stefan Payne
Kokü-Junkie (m/w)
@DaStash
Es ist in einigen Gebieten der Welt üblich, sich erstmal für einen Fehler zu entschuldigen und dann zu schauen, worans gelegen hat.
Das was man allgemein als asiatischer Raum bezeichnet sprich Japan und umliegend.
Ein Deutscher Fahrstuhlhersteller hat nämlich mal das Problem in diesem Raum gehabt, das denen ein Fahstuhl abgestürzt ist, sie haben sich auch nicht erstmal entschuldigt sondern die Vorwürfe abgestritten - ganz dummer Fehler, der ihnen einige Kunden gekostet hat...
@perv
Der Grund, warum ich auf dem Problem mit dem USB Audio Gerät rumreite ist ganz einfach: Davon haben wir als Enduser ganz schnell was!
Hier brauchst du auch nicht versuchen das Problem abzustreiten, Intel schreibt ja durchaus recht klar, das die Probleme da sind und auch nicht gerad selten, ganz im Gegenteil.
@Rest
Schaut euch doch mal das Intel Dokument an!
Es ist wirklich interessant, was da zu lesen ist.
Da gibts z.B. noch ein paar andere Fehler, z.B. wenn man 'nen Rank beim Speicher schlafen legt (Power Down), liefert der Speichercontroller Müll.
Oder AAJ17: General Protection (#GP) Fault May Not Be Signaled on Data Segment Limit Violation above 4-G Limit.
Workaround: 32bit Software sollte halt nicht über 4G zugreifen.
AAJ36 ist auch ganz lustig: ein Kern mag nicht aus dem Tiefschlaf aufwachen
Gut, eher harmlos aber nicht unlustig.
AAJ39. Memory Controller May Deliver Incorrect Data When Memory Ranks Are In Power-Down
Das klingt richtig fies, heißt wohl im Klartext, das das BIOS den Speicher nie schlafen legt, da es sonst zu Datensalat kommt.
Und noch viele andere 'nette' Bugs...
Es ist in einigen Gebieten der Welt üblich, sich erstmal für einen Fehler zu entschuldigen und dann zu schauen, worans gelegen hat.
Das was man allgemein als asiatischer Raum bezeichnet sprich Japan und umliegend.
Ein Deutscher Fahrstuhlhersteller hat nämlich mal das Problem in diesem Raum gehabt, das denen ein Fahstuhl abgestürzt ist, sie haben sich auch nicht erstmal entschuldigt sondern die Vorwürfe abgestritten - ganz dummer Fehler, der ihnen einige Kunden gekostet hat...
@perv
Der Grund, warum ich auf dem Problem mit dem USB Audio Gerät rumreite ist ganz einfach: Davon haben wir als Enduser ganz schnell was!
Hier brauchst du auch nicht versuchen das Problem abzustreiten, Intel schreibt ja durchaus recht klar, das die Probleme da sind und auch nicht gerad selten, ganz im Gegenteil.
@Rest
Schaut euch doch mal das Intel Dokument an!
Es ist wirklich interessant, was da zu lesen ist.
Da gibts z.B. noch ein paar andere Fehler, z.B. wenn man 'nen Rank beim Speicher schlafen legt (Power Down), liefert der Speichercontroller Müll.
Oder AAJ17: General Protection (#GP) Fault May Not Be Signaled on Data Segment Limit Violation above 4-G Limit.
Workaround: 32bit Software sollte halt nicht über 4G zugreifen.
AAJ36 ist auch ganz lustig: ein Kern mag nicht aus dem Tiefschlaf aufwachen
Gut, eher harmlos aber nicht unlustig.
AAJ39. Memory Controller May Deliver Incorrect Data When Memory Ranks Are In Power-Down
Das klingt richtig fies, heißt wohl im Klartext, das das BIOS den Speicher nie schlafen legt, da es sonst zu Datensalat kommt.
Und noch viele andere 'nette' Bugs...
Zuletzt bearbeitet:
sega1
Freizeitschrauber(in)
Ich lebe jetzt schon seit Januar 2008 mit dem Phenom 9500 und seinem TLB Bug, aufgetreten ist er noch nie, und das obwohl ich den Rechner 24/7 betreibe 
. Der TLB Bug bei den Intels wird sich wohl auch nicht so oft zeigen, daher ist es zwar für mich als AMD Fan schön zu lesen 
, aber mehr auch nicht. Als nächste CPU kommt der Phenom II 940 
in meinen Rechner, dann ist der TLB bei mir geschichte... 
. Der TLB Bug bei den Intels wird sich wohl auch nicht so oft zeigen, daher ist es zwar für mich als AMD Fan schön zu lesen , aber mehr auch nicht. Als nächste CPU kommt der Phenom II 940 in meinen Rechner, dann ist der TLB bei mir geschichte... 
Ob4ru|3r
PCGH-Community-Veteran(in)
Ich möchte aber fast wetten, dass jeder Prozessorhersteller ein nettes Kompendium von Fehlern in seiner Hardware hat, und dass die sich - für Außenstehende - ebenso schrecklich lesen mögen ... bin aber nicht fanatisiert genug jetzt nach einem AMD Errata zu suchen ...
und nur so nebenbei: Man kann durchaus mit Software noch einiges reißen, wenn die Hardware Unzulänglichkeiten aufweist ...
DaStash
PCGH-Community-Veteran(in)
Und ich dachte immer das man sein Gesicht verliert, wenn man sich in den "Asiatische Räumen" für etwas entschuldigt?
Deshalb gibt es doch speziell dort Unternehmen die das für einen erledigen, so das man sein Gesicht wahren kann?!
MfG
Korn86
PCGH-Community-Veteran(in)
Es geht darum dass versucht wird den Fehler wie schon genügend andere Fehler gar nicht erst groß publik zu machen oder das sogar versucht wird den Fehler herunter zu spielen
Stefan Payne
Kokü-Junkie (m/w)
Ja, deshalb hab ich auch nicht verstanden, warum bei AMDs B2 Step K10 so ein Aufstand gemacht wurd, zumal niemand genau wusste, was denn nun Sache ist.Ich lebe jetzt schon seit Januar 2008 mit dem Phenom 9500 und seinem TLB Bug, aufgetreten ist er noch nie, und das obwohl ich den Rechner 24/7 betreibe
Das AMD die Server CPUs zurückgepfiffen hat, ist ja durchaus verständlich, zumal einige AMD CPUs auch in Supercomputer wandern und das nicht wenige!
Wer sich mal die Top10 der Supercomputer Top 500 angeschaut hat, wird eine erschlagende AMD Dominanz feststellen, gut einige Rechner haben nicht nur Opterons drin sondern z.B. auch Cells, aber das ist eh die Zukunft der Rechner, das man einmal einen 'schwachen' GP Prozessor hat und dann noch einen richtig starken Streamprozessor.
Ach, wie mich solche relativierungen ankotzen...
Sorry, aber dieser 'abba der hat mir zuerst den Lutscher geklaut' gerede nervt einfach nur noch tierisch, besonders wenn man mal schaut was Intel so für Fehler hat, gehts ganz schnell los...
Außerdem gehts in diesem Thread eher weniger um 'andere Hersteller' sondern Intel, die Versuche abzulenken sind hier auch nicht wirklich hilfreich...
Ja und man kann auch Prozessoren so bauen, das man sie nicht mit Software 'ausnutzen' kann, die Meisterleistungen der Programmierung wirst sicher auch kennen, die uns z.B. das A20 Gate beschert haben oder den AMD K6 Patch für Windows 95, was abgestürtzt ist, weil M$ einen etwas arg dämlichen Timer geschrieben hat, der auf den K6 sehr schnell ausgeführt wurde (ja, es ist der legendäre loop Befehl), so dass die Berechnungen des Timers schneller waren als Dinge, auf die gewartet werden mussten und für die der Timer programmiert werden musste...
Ja, das ist etwas komplizierterUnd ich dachte immer das man sein Gesicht verliert, wenn man sich in den "Asiatische Räumen" für etwas entschuldigt?
Deshalb gibt es doch speziell dort Unternehmen die das für einen erledigen, so das man sein Gesicht wahren kann?!
Das Gesicht verliert man (schon) für die Fehler die passieren.
Man streitet aber dann nichts ab, man entschuldigt sich dann erstmals und versucht diesen Fehler aus der Welt zu schaffen, wie es z.B. Toyota mit den 1ZZ-FE Motoren getan hatten, die an einem sehr hohen Ölverbrauch litten. Bei manch einem Deutschen Hersteller wurde das ja unter den Tisch gekehrt, besonders bei deren glorreichen 1.4l/16V Teilen...
Ob4ru|3r
PCGH-Community-Veteran(in)
War wohl mehr so rum, dass es bisher keinem aufgefallen war, bis mal wer ins Errata geschaut hat ...Es geht darum dass versucht wird den Fehler wie schon genügend andere Fehler gar nicht erst groß publik zu machen oder das sogar versucht wird den Fehler herunter zu spielen
Wenn ein Fehler nicht auffällt - wenn er zum Beispiel vorab durch Anweisung an die Entwickler in der Software umschifft wird, wie bei Intels TLB-Bug geschehen - dann gibts halt keine große Aufregung, warum auch ?! ISt'n Bugfix, sowas macht MS am laufenden Band ....
Beim Phenom fiel es halt auf, als der Fehler noch ungefixt war, entsprechend ging dann das (von Fanboys in den Foren befeuerte) massenhafte Geflame über den Phenom los, obwohl eigentlich nie jemand selber besagten Bug hatte, trotz Dauerbetrieb ..... au man, so viel Strees um nix
Von daher ist es nur verständlich, dass einige jetzt wiederum auf Intel's "Fehlern" rumreiten, jetzt, wo mit dem Errata und den ganzen super fiesen Fehlerbeschreibungen drin mal endlich Munition zum Zurückschießen da ist ... Rache ist halt süß
Ich will ja nicht wissen, wie das wieder abgeht, wenn der Phenom 2 da ist
No comment ....
Da will man darauf hinweisen, dass dass nicht nur das böse Intel Imperium macht, und schon kommt der Stefan daher und ist mal wieder angepisst, weil man ihn in seinem Rausch ausgebremst hat ^^
Das das Fixen per Software auch gerne mal schief läuft, oder auch mal gar nicht möglich ist habe ich nie bestritten, ich habe nur gesagt, dass man auch mit Software noch was reißen kann .... mein X2 4200+ bespielsweise wollte damals auf meinem Board K8NF9 trotz neustem BIOS net laufen ... erst 2 "Patches" seitens AMD brachten da Abhilfe, und ich hatte meien zweiten Kern, bzw. die unerklärlichen Abstüzre die ich auf einmal recht regelmäßig hatte hörten auf ... k.a., ob das ein Hardwarefehler war, hatte mich damals nicht wirklich interessiert (falls nicht, werd ich von dir jetzt eh wieder eine auf die Nuss kriegen xD) .... aber ein Softwareflicken hat halt Abhilfe geschaffen, bei scheinbar nicht richtig funktionierender Hardware
Zuletzt bearbeitet:
DaStash
PCGH-Community-Veteran(in)
Ja, das ist etwas komplizierter
Das Gesicht verliert man (schon) für die Fehler die passieren.
Man streitet aber dann nichts ab, man entschuldigt sich dann erstmals und versucht diesen Fehler aus der Welt zu schaffen, wie es z.B. Toyota mit den 1ZZ-FE Motoren getan hatten, die an einem sehr hohen Ölverbrauch litten. Bei manch einem Deutschen Hersteller wurde das ja unter den Tisch gekehrt, besonders bei deren glorreichen 1.4l/16V Teilen...
Das ist aber schon ein grober Fehler.
Ich meinte eher kleinere Fehler. Diese erwähnt man nicht öffentlich sondern versteckt sie in irgendwelchen Dokumenten(man will ja nicht kompl. lügen) so das sie eben kaum jemanden auffallen.
Aber egal, ich verstehe schon was du meinst.
Wirklich interessant wird doch diese Diskussion hier erst, wenn bekannt ist in wie weit die Verbesserungen sich auf die Performance auswirken werden. Das war ja der Punkt der bei den Phenoms so stark kritisiert wurde. Mir schweben da immernoch zahlen seitens der pcgh im Kopf rum, von bis zu 20% Einbuße. Mal sehen wie Intel das Problem löst.
p.s. Ich fand die Diskussion damls schon absolut theoretisch und sinnlos, da dieser "TLB" Fehler nie reproduziert werden konnte. Einzig alleine die negative PR und Publicity die gegen AMD gefahren wurden, fand ich sowohl von der Seite der pcgh aus(mit dem ständigen Hinweis auf die 20% Einbuße und den andauernden Test mit dem per Bios beh. TLB Bug Prozis), als auch von vielen anderen Medien ziemlich einseitig und undifferenziert.
Mal sehen ob sich dies in dem Fall auch wiederholen wird^^
MfG
ITpassion-de
PCGH-Community-Veteran(in)
Wie man auf CB eben lesen konnte hatte Intel den "Bug" schon vor dem erscheinen des i7 per BIOS Update gefixt.
DaStash
PCGH-Community-Veteran(in)
Jetzt ist es noch interessant in wie weit sich das auf die Performance auswirkt.
MfG
ITpassion-de
PCGH-Community-Veteran(in)
Kann man ja nicht sagen, da keine i7 Systeme mit TLB Bug verkauft wurden. Also womit willst du vergleichen?
Im übrigen frag ich mich, wenn die derzeit gebotene i7 Leistung gedrosselt ist wie pervers soll die Performance dann erst sein wenn er ein neues Stepping bekommt?
DaStash
PCGH-Community-Veteran(in)
In der Tat, hast Recht
Ich bin auch gespannt wie die tatsächliche Leistung des I7 sein wird und vor allem in wie weit die Mehrkernoptimierung-/Unterstützung, im Anwenderbereich, in naher Zukunft des I7 ausfallen wird.
MfG
perv
Komplett-PC-Aufrüster(in)
Intel PR Manager Dan Snyder:
The "AAJ1 Clarification of TRANSLATION LOOKASIDE BUFFERS" document is a SPEC CLARIFICATION, and is simply a pointer to a previous document written in April 2007.
SPEC CLARIFICATION AAJ1 was initially added due to an issue on the Intel® Core 2 Duo processor which was previously corrected with a BIOS update; this issue does not impact the Nehalem Family of CPUs. There are errata on the Intel Core i7 processor that relate to the TLB. These all relate to improper translations or error reporting, and all of those that impact functionality have been fixed via BIOS updates prior to Core i7 launch.
The "AAJ1 Clarification of TRANSLATION LOOKASIDE BUFFERS" document is a SPEC CLARIFICATION, and is simply a pointer to a previous document written in April 2007.
SPEC CLARIFICATION AAJ1 was initially added due to an issue on the Intel® Core 2 Duo processor which was previously corrected with a BIOS update; this issue does not impact the Nehalem Family of CPUs. There are errata on the Intel Core i7 processor that relate to the TLB. These all relate to improper translations or error reporting, and all of those that impact functionality have been fixed via BIOS updates prior to Core i7 launch.
DaStash
PCGH-Community-Veteran(in)
Wäre tzd. interessant zu welchen Performanceeinbußen diese Biosfixes geführt haben.
Wie aber schon it-passion bemerkt hatte, wird es schwierig sein objektive Benches der Prelauncheserie zum Vergleich herzuziehen.
MfG
Stefan Payne
Kokü-Junkie (m/w)
Ja und was ist mit den anderen Bugs die den TLB betreffen?!
AAJ1 ist ja nicht der einzige, gibt da ja noch einige mehr...
AAJ1 ist ja nicht der einzige, gibt da ja noch einige mehr...
ITpassion-de
PCGH-Community-Veteran(in)
Suchst du jetzt verzweifelt irgendwas zum darauf herum hacken?
Scorpioking78
Software-Overclocker(in)
So wie sich das Inteldokument liest, sind die Nehalems mit dem TLB-Bug behaftet. Und eine Lösung wird für die folgenden Monate erwartet.
Stand des Doc 11/2008
Folgendes Dokument beschreibt, wie der TLB-Bug vermieden werden kann.
http://download.intel.com/design/processor/manuals/253668.pdf
Das Problem scheint darin zu liegen, dass der zum Freigeben der TLB-Einträge verwendete Befehl "INVLPG" (dieser bietet die beste Performance, wenn der gesamte TLB freigeben wird) nicht durch die G_Flag beeinflussbar ist. Es werden dadurch also auch mit der G_Flag versehene Einträge freigegeben, die evtl.von einem anderen Core gesetzt worden sind und damit würde dieser Core einen Datenverlust erleiden.
Als Programmierer sollte man also wissen, was man alles freigeben darf vom Cache und was nicht und man sollte dann die entsprechenden Befehle nutzen. D.h. dass der Cache wegen unsachgemäßer Programmierung Datenmüll provozieren könnte, weil durch das Freigeben der mit G_Flag gekennzeichneten Speicherbereiche diese von nem anderen Core belegt werden können und der vorherige Core würde dann evtl sinnlose Daten erhalten, wenn er auf eigentlich seinen reservierten Bereich des L3 zugreift.
Ich hoffe mal, dass ich das soweit richtig verstanden habe, was Intel da ausgeführt hat.
Insofern wäre es also nur ein Bug, wenn der "INVLPG"-Befehl die G_Flag beachten sollte.
Zuletzt bearbeitet:
Ich plane meinen Rechner meiner Tochter zu geben und mir einen I/7 920 zu kaufen. Sind bei dir in der Anwendung Fehler aufgetreten die relevant waren?
