Phenom hält mich auf T(LB)rab

Hallo miteinander,

wie ich kürzlich in einem anderen Thread berichtete, habe ich meinen Athlon 64 X2 5000+ durch einen Phenom 9600 BE ersetzt. Am restlichen System (Netzteil, Speicher, HDDs, OS, etc.) wurde nichts verändert außer das BIOS 2.23 für das ASRock ALiveNF6G-DVI geflasht, das für die Phenom-Erkennung nötig ist. Das BIOS hat noch keinen TLB-Fix implementiert.

Da es sich um einen Black Edition handelt, habe ich anfangs natürlich erst einmal probiert, wie weit sich diese CPU per Multiplikator übertakten lässt. Leider musste ich feststellen, dass bereits ab 2,6 GHz Windows beim Booten hängenbleibt, egal welche VCore man wählt. 2,5 GHz dagegen waren problemlos drin und "primestable" machbar.

Nun muss man dazusagen, dass der PC bei mir rund um die Uhr 365 Tage im Jahr läuft, da er auch als Faxgerät und LAN-Fileserver dient. Zudem läuft grundsätzlich BOINC. Das heißt, das System ist permanent voll ausgelastet. Da der PC zudem noch als Digitaler Video-Rekorder genutzt wird, muss er gleichzeitig auch häufig DVB-Streams schneiden und umwandeln. Also zugegebenermaßen kein alltägliches Einsatzprofil.

Nun ist es mir bereits letzte Woche einmal passiert, dass das System festgefroren ist. Die Maus ließ sich zuerst noch bewegen, während alle Anwendungen im Hintergrund nicht mehr reagierten. Nach ein paar weiteren Sekunden stand auch der Mauszeiger still.

Da dachte ich noch "ok, vielleicht ist die CPU mit 2,5 GHz im Dauerbetrieb doch zu nahe am Limit gebaut" (obwohl primestable). Daraufhin habe ich den CPU-Takt letzte Woche auf 2,4 GHz reduziert. Geholfen hat's leider nichts. Nach wieder ungefähr der selben Zeit (~4-5 Tage) ist das System erneut festgefroren, wieder mit den gleichen Symptomen wie oben beschrieben. Und das lässt meine Augenbrauen doch etwas nach oben wandern.

Nun könnte jemand natürlich hergehen und sagen, das sei ganz normal für Windows XP, ganz normal für ein Desktop-System, ganz normal für weiß Gott was. Aber da kann ich nur entgegnen: nein, das ist definitiv nicht normal! Dieses System - also nicht ein ähnliches, nicht das gleiche, sondern das selbe - lief mit dem Athlon 64 X2 5000+ achteinhalb Monate (!!!) durch ohne ein einziges Mal rebootet worden zu sein, ohne Absturz, ohne Freeze, ohne Probleme. Die Aufgaben waren dabei die gleichen (BOINC, Fax, DVB-S, Encoden, etc.).

Ich will keine voreiligen Schlüsse ziehen, denn noch immer ist das System von 2,3 GHz auf 2,4 GHz übertaktet (wenn auch erneut primestable). Ich werde jetzt alles, inklusive VCore, Multiplikator, etc. auf Default zurücksetzen und dann sehen wir mal in 4-5 Tagen was los ist. Die Symptome (Freeze unter massiver Dauerlast über mehrere Tage auf allen 4 Kernen) würden jedenfalls zum TLB-Bug passen. Leider gibt's weder einen Eintrag im Eventlog, noch einen Crashdump. Das System bleibt einfach stehen, sodass auch die Analyse schwierig ist. Jedenfalls ist es ärgerlich (aufgrund welcher Ursache auch immer) ein rocksolid System eingetauscht zu haben gegen eines, das jede Woche einmal in Streik tritt.

Ich halte Euch auf jeden Fall auf dem Laufenden.

Ach ja, der Vollständigkeit halber das System:

Mainboard: ASRock AliveNF6G-DVI
Speicher: 2x MDT DDR2-800 CL5 in Dual-Channel Konfiguration (bei Phenom zusätzlich Unganged)
Kühler: Scythe Ninja
Netzteil: Enermax Liberty 500W
HDDs: 3x Seagate Barracuda ST3250620AS

Nero24 schrieb:

Ich will keine voreiligen Schlüsse ziehen, denn noch immer ist das System von 2,3 GHz auf 2,4 GHz übertaktet (wenn auch erneut primestable). Ich werde jetzt alles, inklusive VCore, Multiplikator, etc. auf Default zurücksetzen und dann sehen wir mal in 4-5 Tagen was los ist.

Zum Vergrößern anklicken....

Genau das würde Licht in die Sache bringen, alles andere ist (da ausserhalb der Specs) reine Vermuterei, weil vllt AMD gar nichts dazu kann.
Bin mal gespannt auf die Ergebnisse, zumal ich schon gern wieder AMD in der Kiste hätte.

Sehr ärgerlich. Deswegen finde ich es von AMD auch so unverschämt eine instabile CPU auszuliefern und keine Rückrufaktion zu starten. Ich schätze mal das laufen lassen auf den default Werten wird eben wegen dem Bug auch nichts bringen. Drück dir natürlich trotzdem die Daumen. Da hilft nur ein der Performance raubende Fix oder eben ein Wechsel auf das B3 Stepping, wenn verfügbar. Wie gesagt, sehr sehr ärgerlich das Ganze...

Und das gerade DU solch eine Kritik ausübst sagt alles......

Patmaniac schrieb:

Deswegen finde ich es von AMD auch so unverschämt eine instabile CPU auszuliefern und keine Rückrufaktion zu starten.

Zum Vergrößern anklicken....

hä?

Ich denke nicht, dass dies eine Folge des Erratum 298 ist. Zwar soll dieser auch zum Einfrieren des Systems führen, aber in manchen Fällen auch nur zur Datenkorruption. Darauf sollte es dann Anzeichen in der Ereignisanzeige geben. Deswegen würde ich vermuten, dass die Abtürze bei dir Folge des Betriebs außerhalb der Spezifikationen oder eines anderen Bugs sind. Ob dieser im Prozessor oder in der Firmware des Mainboards verankert ist, wirst du wohl nur durch einen Austausch des Mainboards herausfinden. Am Besten tauscht du zugleich auch noch den Arbeitsspeicher gegen höherwertigen aus.

SPINA schrieb:

Am Besten tauscht du zugleich auch noch den Arbeitsspeicher gegen höherwertigen aus.

Zum Vergrößern anklicken....

und warum nimmst Du an, das Quimonda "hochwertiger" als MDT ist?

Albatroner schrieb:

und warum nimmst Du an, das Quimonda "hochwertiger" als MDT ist?

Zum Vergrößern anklicken....

Aufgrund meiner bisheringen Erfahrungen mit MDT.

PS: Es heißt Qimonda. Aber es muss nicht Qimonda sein, Aeneon und Samsung sind auch nicht schlecht.

SPINA schrieb:

Am Besten tauscht du zugleich auch noch den Arbeitsspeicher gegen höherwertigen aus.

Zum Vergrößern anklicken....

Wieso sollte ich einen Arbeitsspeicher austauschen, der mit dem Athlon 64 über 8 Monate nonstop fehlerfrei durchgelaufen ist ohne einmal neu gestartet worden zu sein? Welches noch höhere Stabilitätsprädikat kann ein Desktop-RAM noch erreichen?

Aber der DRAM Controller wurde durch einen anderen ersetzt. So wie Arbeitsspeicher bei Intel Plattform nicht auf jedem Mainboard gleich gut läuft, so verhält es sich bei AMD mit den unterschiedlichen Prozessorgenerationen. Manche Steppings des K8 haben beispielsweise mit der Vollbestückung auf allen vier Bänken Schwierigkeiten und müssen dann den Speichertakt drosseln, manche haben Steppings haben dann wieder Probleme beim Einsatz von drei DIMMs und so weiter. Deswegen kann es sein, dass Speicher, welcher bei der K8 Plattform keine Auffälligkeiten gezeigt hat, sich mit dem K10 nicht als kompatibel erweist und Daten korrumpiert. Gerade angesichts der großen Änderungen mit dem Ganged und Unganged Mode.

EDIT: Im Threadtitel ist übrigens ein Rechtschreibfehler: "Phenom hält mich auf T(LB)rab"

Mir ist schon klar, dass nicht jeder Arbeitsspeicher zu jedem Memory-Controller passt Es ging mir in diesem Fall um Deine Aussage meine RAMs durch "höherwertigere" zu ersetzen, ein Attribut, das in meinen Augen im Falle von MDT nicht angebracht ist, da ich widerum bisher nur gute Erfahrung mit MDT hatte, vor allem in der DDR1-Zeit mit den BGA-RAMs. Aber lassen wir das.

Natürlich kann die Abstürze erst einmal alles mögliche verursachen wie schon geschrieben wurde: ein Fehler im neuen BIOS, eine Inkompatibilität zwischen Speicher und Memory-Controller, etc.

Aber man sollte nicht vergessen, dass das System vermutlich von 95% der Anwender als rocksolid bezeichnet würde. Prime läuft bis zum Abwinken fehlerfrei durch, es gibt keine sonstigen Auffälligkeiten. Einem User, der sein System ein paar Stunden am Tag nutzt und dann jeweils ausschaltet, wäre dieses spezielle Problem nie untergekommen. Es bedarf etlicher Tage Nonstop-Dauerlast, um darauf zu stoßen!

Ich meine, ich bin auch nicht grad ein N00b und habe quasi täglich mit der Instandsetzung von instabilen Kunden-Systemen zu tun, wo eben defekte Komponenten oder Inkompatibilitäten eine Rolle spielen. Da ist das aber mit den entsprechenden Tests nach wenigen Sekunden (Defekte) oder spätestens einigen Stunden (Inkompatiblitäten) zu reproduzieren. Dass solche Dinge (Inkompatiblitäten, Defekte, minderwertige Teile) erst nach etlichen Tagen absoluter Dauervollast zum Absturz führen und dann auch noch immer auf die selbe Weise, ist mir bisher noch nie untergekommen.

Schon komisch, aber wohl "normal" beim derzeitigen Entwicklungsstand (beta).
Dein Problem ist aber wohl leider nur sehr schwierig nachzuvollziehen, soll heißen, bis da ein BIOS Patch dafür rauskommt (so überhaupt möglich) wird mind. halbes Jahr vergehen.

Vielleicht ist es auch irgendein andrer Bug, gibt ja nicht nur den TLB ...

Ansonsten, vielleicht noch ein Tipp, an den Du sicherlich schon selber gedacht hast, was machen die Spannungswandler ? Mit dem oc K10 haben die sicherlich mehr zu tun, als mit dem alten dual core. Lass eventuell nen extra Lüfter draufblasen. VIel Hoffnung hab ich da allerdings nicht, ich denke die Lösung ist komplizierter

ciao

Alex

wie schaut es bei dir mit der möglichkeit den rechner täglich zu einer zeit wo du garantiert nichts dran machst automatissch neustarten zu lassen?
ist zwar keine prduktive hilfe ein problem zu lösen, aber würde warscheinlich erstmal das problem umgehen.

Könnte eventuell ein nicht ganz ausgegorenes BIOS Probleme mit der Phenomunterstützung haben? Das würde sich für mich am plausibelsten anhören, denn ein Speicherproblem ist nach der intensiven Testerei mit Prime doch eher unwahrscheinlich...

Ein Bios der den TLB Bug umgeht gibt es für dein Mainboard noch nicht? Ja ich weis, das kostet Leistung, aber in deinem Fall wäre vielleicht es doch besser, zumindest zum austesten .

cpushreder schrieb:

wie schaut es bei dir mit der möglichkeit den rechner täglich zu einer zeit wo du garantiert nichts dran machst automatissch neustarten zu lassen?
ist zwar keine prduktive hilfe ein problem zu lösen, aber würde warscheinlich erstmal das problem umgehen.

Zum Vergrößern anklicken....

Naja, das ist schwierig. Wenn nur BOINC liefe wäre es kein Problem den Rechner jeden Tag Nachts um 4 Uhr automatisch neu starten zu lassen bis es eine Lösung für das Problem gibt. Aber dazu müsste man erst einmal wissen, was das Problem ist Zudem kann es beim Encoden vorkommen, dass der auch schon mal anderthalb Tage an einem Film herumrechnet wenn aufwändige Filter (Smart-Deinterlace, Denoiser, etc.) im Spiel sind und dann wäre es ziemlich blöd wenn der Taskplaner dem System kurz vor Schluss den Saft abdrehen würde, um den geplanten Neustart durchzuführen

LarsPower schrieb:

Ein Bios der den TLB Bug umgeht gibt es für dein Mainboard noch nicht? Ja ich weis, das kostet Leistung, aber in deinem Fall wäre vielleicht es doch besser, zumindest zum austesten .

Zum Vergrößern anklicken....

Nein, bisher gibt's noch kein BIOS mit Fix - und wenn es eines gäbe, würde ich ihn nicht dauerhaft aktivierten (außer zum Gegencheck, ob's wirklich daran liegt). Lieber bau ich den X2 wieder ein und erfreue mich an der niedrigeren Stromrechnung, als einen Quad-Core mit angezogener Handbremse zu betreiben.

Ich bin das Abenteuer Phenom trotz altem AM2-Board und trotz B2-Stepping bewusst eingegangen, natürlich nicht, weil mir langweilig war und ich unbedingt auf den TLB-Bug stoßen wollte, sondern um von Schwierigkeiten beim Umstieg berichten zu können und evtl. wertvolle Tipps geben zu können, wie z.B. dass man vor dem CPU-Wechsel den Dual-Core Optimizer deinstallieren muss und dergleichen. Dass ich in der Realität auf den TLB-Bug stoßen könnte, daran hatte ich nie einen Gedanken verschwendet nach den Informationen ("unter Laborbedingungen", "unter seltenen Umständen", "nur bei Virtualisierung", "nur theoretisch", etc.) die verfügbar sind. Gut, noch wissen wir nicht, ob es der TLB-Bug ist, der dafür verantwortlich ist, aber wenn er es sein sollte, ist sein Auftreten wohl doch nicht soooo unwahrscheinlich, dass er für den Anwender keine Rolle spielt.

Ansonsten, vielleicht noch ein Tipp, an den Du sicherlich schon selber gedacht hast, was machen die Spannungswandler ? Mit dem oc K10 haben die sicherlich mehr zu tun, als mit dem alten dual core.

Zum Vergrößern anklicken....

Vor dem Brisbane war zwei Monate lang ein Windsor mit F2-Stepping eingebaut, der ebenfalls ordentlich Strom gezogen hat. Auch damit war nie was, daher würde ich die Spannungswandler eher ausschließen. Zudem zieht ein 140 mm Gehäuselüfter ein paar Zentimeter neben den Spannungswandlern ordentlich Luft nach Draußen, sodass die Luft immer in Bewegung ist und Hitzenester an den Wandlern eher unwahrscheinlich sind. Ausschließen könnte ich es aber natürlich erst mit einem "besseren" Board.

Jetzt gucken wir doch erst einmal, was der Dauertest mit "by Default" Einstellungen zu Tage bringt.

LarsPower schrieb:

Ein Bios der den TLB Bug umgeht gibt es für dein Mainboard noch nicht?

Zum Vergrößern anklicken....

Es wird ,Meine ich, auch nie so ein Bios geben. Wenn wird dein L3 ganz abgeschaltet.

Ich muss leider auch sagen, das auch mein System zu früher nicht ganz stabil läuft. Da ich allerding meinen PC meist eh öfter mal neu starte ist es nicht ganz so schlimm.
Denke mit der Zeit werden dahin gehend auch neue Bios Versionen kommen und einige Sache noch gefixt werden.
Zudem werden neuere Phenoms mit einiges fixes noch andere Probleme lösen.
Ich hatte derzeti leider noch keine Möglichkeit auf einem 790er zu testen, da mein derzeitiges 570er schnell genug ist werde ich auch nicht so schnell wechseln.

dekaisi schrieb:

Es wird ,Meine ich, auch nie so ein Bios geben. Wenn wird dein L3 ganz abgeschaltet.

Zum Vergrößern anklicken....

Wieso, für die meisten anderen Boards gibt's doch so ein BIOS. Dabei wir übrigens nicht der L3 abgeschaltet, sondern der betroffene Teil des L2-TLB (mit den bekannten Performance-Einbrüchen):
http://www.planet3dnow.de/vbulletin/showthread.php?t=330868

...nur für mein Board gibt's halt noch kein BIOS mit diesem Fix.

das Bios ist völliger humbig, da das eigentliche Problem damit nicht gefixt ist.

dekaisi schrieb:

das Bios ist völliger humbig, da das eigentliche Problem damit nicht gefixt ist.

Zum Vergrößern anklicken....

Hast Du unsere Berichterstattung in den letzten Wochen nicht verfolgt?

Der Bug ist dadurch natürlich nicht gefixt. Aber der fehlerhafte Teil des Translation Lookaside Buffer wird bei Aktivierung des Fix schlichtweg nicht genutzt, daher kann auch der aus dem Bug resultierende Fehler nicht mehr auftreten. Aber natürlich geht das Deaktivieren eines Features auf Kosten der Performance, denn der TLB ist ja nicht völlig umsonst in einer modernen CPU eingebaut

Wenn es Dich interessiert, was ein TLB eigentlich macht, kann ich Dir diesen Artikel empfehlen:
http://www.lostcircuits.com/cpu/amd_phenom/2.shtml

Ich habe es gelesen.
Wozu so einen Einbruch hin nehmen wenn der CPU normal ohne Probleme läuft?
Zudem müsste doch AMD längst aktuelle Produkte umgestellt haben, selbst wenn diese nicht B3 sind. Siehe laut Quartalszahlen wurden 400.000 Quad ausgeliefert, meinst du diese hätten alle den "ominösen Bug"? Wäre zu bezeifeln.

Was ist eigentlich bei dem AMD Day raus gekommen? Wurde diese Frage da mal gestellt?

dekaisi schrieb:

Zudemmüsste doch AMD längst aktuelle Produkte umgestellt haben, selbst wenn diese nicht B3 sind. Siehe laut Quartalszahlen wurden 400.000 Quad ausgeliefert, meinst du diese hätten alle den "ominösen Bug"? Wäre zu bezeifeln.

Zum Vergrößern anklicken....

Hehe Chip-Produktion ist nicht mit einem Röhrenradio zu vergleichen, wo man mal schnell was hinbiegt und dann funktioniert das wieder

Ein Wafer ist etliche Wochen in den Produktionshallen unterwegs, bis er fertig belichtet, geäzt, gewaschen, wieder belichtet, wieder geäzt, etc. ist. Anschließend müssen die Wafer nach Malaysia verschickt, geschnitten, auf das Gehäuse gepackt, getestet, und gelabelt werden. Anschließend geht's wieder zurück in den Vertrieb. Das bedeutet, selbst wenn AMD den Fehler sofort am 19. November nicht nur erkannt hätte, sondern auch gleich die Lösung parat gehabt hätte, hätte es 8-10 Wochen gedauert, bis die Wafer mit den gefixten Schaltkreisen am Ende des Fließbandes herausgepurzelt wären. Scheinbar haben sie den Fehler aber nicht gleich beheben können, sonst müsste es mittlerweile CPUs ohne Erratum 298 geben.

Wenn AMD in dieser Zeit alle angefangenen Wafer mit dem B2-Stepping auf den Müll geworfen hätte, hätten sie in dieser Zeit keine Phenoms mehr liefern können. Im Serverbereich haben sie das tatsächlich durchzogen, denn derzeit werden ja keine Quad-Core Opterons ausgeliefert. Für den Desktop-Markt dagegen haben sie den Bug in Kauf genommen und die CPUs trotzdem ausgeliefert - unter der Voraussetzung, dass die Mainboard-Hersteller die defekten Schaltkreise und damit für die Performance wichtige Features per BIOS deaktivieren. Gut für AMD, denn so konnten sie wie Du sagtest 400.000 Quad-Core CPUs verkaufen, schlecht für den Anwender, der sich entscheiden muss zwischen voller Leistung und einem möglicherweise auftretenden Bug oder einer CPU mit deaktivierten Schaltkreisen und verminderter Leistung.

Würde mich mal intressieren ob das auch unter Linux passiert. Kannste da mal ne LiveCD laufen lassen mit BOINC/Folding?
Sollte dort was ähnliches passieren, kann man sich recht sicher sein das es mit der CPU zu tun hat.

Dass ich in der Realität auf den TLB-Bug stoßen könnte, daran hatte ich nie einen Gedanken verschwendet nach den Informationen ("unter Laborbedingungen", "unter seltenen Umständen", "nur bei Virtualisierung", "nur theoretisch", etc.) die verfügbar sind. Gut, noch wissen wir nicht, ob es der TLB-Bug ist, der dafür verantwortlich ist, aber wenn er es sein sollte, ist sein Auftreten wohl doch nicht soooo unwahrscheinlich, dass er für den Anwender keine Rolle spielt.

Zum Vergrößern anklicken....

Könntest du ja ausschließen. Hau dir ein Linux mit dem entsprechendem Kernelpatch drauf und lass Boinic laufen (wobei der andere Kram zwar relativ schnell aufgesetzt ist, aber dann doch etwas Arbeit wäre). Tritt der Bug nicht auf hast du ein anderes Problem und kannst TLB ausschließen

Nero24 schrieb:

Hehe Chip-Produktion ist nicht mit einem Röhrenradio zu vergleichen, wo man mal schnell was hinbiegt und dann funktioniert das wieder

Zum Vergrößern anklicken....

ich weiß sehr wie das funktioniert.8)
Zudem kann ich deine Meinung nicht teilen, man kann sehr wohl Änderungen im laufenden Prozess machen. Man hält die Linie an und versucht durch gezielte kleine Veränderungen dem großejn Schaden erstmal Herr zu werden. Frage wäre ja wenn wo man genau suchen muss.
Klar werden hinten raus schon Produzierte Chips raus gekommen sein, aber die laufen bestimmt dann als <2,4ghz umsonst gab es Plötzlich ja keine 9700 mehr.

Piloboy schrieb:

Würde mich mal intressieren ob das auch unter Linux passiert. Kannste da mal ne LiveCD laufen lassen mit BOINC/Folding?
Sollte dort was ähnliches passieren, kann man sich recht sicher sein das es mit der CPU zu tun hat.

Zum Vergrößern anklicken....

4-5 Tage lang?


Mfg DerrickDeluXe