News Laut AMD keine Probleme mit 3. Phenom-Kern

[MountWalker]

... Und dass der Fehler bisher scheinbar nur bei Vista64 beobachtet werden konnte, sowohl bei AMD als auch Intel, deutet eigentlich eher auf ein OS Problem hin. ...

Muss aber auch nicht. Als ich meinen RAM im Desktop von 2*0,5 auf 2*1 GiB vergrößerte vergaß ich, dass die größeren Module (mit sonst gleichen Specs) möglicherweise mit Cammandrate 1 nicht mehr stabil laufen würden. Auf Windows (in dem Fall allerdings Vista 64) schien dadurch kein Nachteil entstanden zu sein. Das System schien völlig normal zu laufen. Nur der Webbbrowser stürzte ab und zu ab, was ich gar nicht mit einem Hardwarefehler in Verbindung brachte (obwohls daran lag). Erst beim nächsten Linux-Boot wurde mir der Fehler aufgrund einer auch durch Neuinstallation nicht wegzubekommenden Kernel Panic deutlich - Memtest86+ durchlaufen lassen und schwubbs, heidewitzka ab Test3 schon nur noch Fehler.

Es wäre auch möglich, dass Vista, weil es Prozessor und Speicher möglicherweise effektiver verwaltet, anfälliger für bestimmte Hardwarefehler ist, als XP, so wie bspw. Linux noch sehr viel anfälliger für bestimmte hardwarefehler ist - und niemand kommt auf die Idee Linux deswegen als schlechter zu beurteilen.

 

[Tamahagane]

@Situationskomik

Hmm ok is verständlich aber von löschen hat ja keiner gesprochen ^^

@ TotKuh

Danke für die info.

 

[HOT]

MountWalker, das ist mit Sicherheit bei vielen der Fall, bei denen das Sys nicht korrekt läuft. Siehe auch hier:
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1202862699
Nur gibt es das Problem auch bei 100% gut laufenden Systemen. Man muss aber immer dazu sagen: Das ist ein extrem selten auftretendes Phänomen, sowohl bei AMD als auch bei Intel, aber mit Schwerpunkt bei AMD CPUs.

 

[MountWalker]

@ HOT

Ist ja richtig, ich wollte nur darauf hinweisen, dass das, was gruffi aufgriff, kein Indiz für einen OS-Fehler sein muss. Möglicherweise treten Fehler auf Vista häufiger zu Tage, als auf XP, weil das OS besser mit Speicher und Prozessor umgeht.

 

[HOT]

Nope, exakt dieser Fehler tritt nur und ausschließlich unter Vista 64 auf.

 

[Antimon]

Wir können uns auch darauf einigen, dass wenn die AMD Prozessoren einen Fehler hätten, wir bei über 400 000 Prozessoren die sich in bestätigtem Umlauf befinden, schon weit mehr von Problemen gehört hätten als es bis jetzt der Fall ist. Sowas gebietet die einfache Logik.

Interessant wird es jetzt natürlich heraus zu finden warum der Timingfehler auftritt und vorallem warum er anscheinend gehäuft unter Vista 64 zu finden ist.

 

[MountWalker]

@ HOT

Ist das Gerücht, aber welche der "Quellen" kann bestätigen, dass der Fehler auf Fedora Core linux oder OpenSolaris nicht auftritt? Wurden wirklich mehrere 64b-Systeme verglichen?

 

[MacroWelle]

Woher leitet man aus dieser fehlermeldung von Vista einen möglichen Defekt im 3. Kern ab frag ich mich.

Unter anderem aus dem Thread dieses Overclocker-Forums, bei dem dortigen Betroffenen lassen sich alle Kerne außer dem dritten (bezeichnungstechnisch Kern 2) übertakten, sobald der User den dritten Kern übertakten, gibt's Bluescreen.

Nope, exakt dieser Fehler tritt nur und ausschließlich unter Vista 64 auf.

Es scheint auch unter Linux Probleme zu geben. Ob es sich um die gleiche Problematik handelt, ist schwer zu sagen, da auch auf einem 32-Bit-Kernel Probleme auftreten und die CPU trotzdem (ja, alle Kerne) übertaktbar sind (2,2 --> 2,5 Ghz):
http://www.phoronix.com/scan.php?page=article&item=961&num=1
http://www.phoronix.com/scan.php?page=article&item=998&num=1

Das bestätigt übrigens, was Mountwalker gesagt hat - Linux 2.6.22 kann einen jungfräulichen Phenom nur booten, wenn (zumindest was Ubuntu betrifft) die Distribution mit dieser CPU frisch installiert wurde. Weil der Kernel beim booten eben nicht schlampt und somit bei einem schlichten CPU-Wechsel von K8 auf K10 das streiken anfängt (das ist zumindest mein Eindruck aus den Phoronix-Tests).
Das wäre natürlich schwach, wenn AMD beim K10-Start keine ausgereiften Linux-Strukturen (für den Desktop) vorweisen kann.

 

[sturme]

Das bestätigt übrigens, was Mountwalker gesagt hat - Linux 2.6.22 kann einen jungfräulichen Phenom nur booten, wenn (zumindest was Ubuntu betrifft) die Distribution mit dieser CPU frisch installiert wurde.

Sorry aber das ist ein Distributionsproblem, und zum Phenom-Start war bereits 2.6.23 aktuell. Hier muss ich also widersprechen, während ich euch ansonsten zustimme, dass die Vista64-Probleme mit dem Phenom nicht zwangsläufig auf ein Software-Problem hindeuten müssen. Allerdings deuten sie doch eher auf ein Software- als ein Hardware-Problem hin, allein, man kann keines von beidem von vornherein mit Bestimmtheit sagen oder ausschließen. Von daher halte ich diesen Hickhack hier für mehr als entbehrlich (und auch erbärmlich, aber man kennt das ja schon).

 

[gruffi]

Muss aber auch nicht.

Da hast du mich vermutlich falsch verstanden. Ich hatte ja schon erwähnt, dass das Problem vielfältige Ursachen haben kann. Meine Aussage bezog sich vielmehr auf Situationskomik, und dass wenn man erstmal CPU und OS als Ursache in Betracht zieht, das OS wahrscheinlicher ist.

 

[MacroWelle]

Sorry aber das ist ein Distributionsproblem, und zum Phenom-Start war bereits 2.6.23 aktuell.

Phoronix hat den Phenom auch mit 2.6.24 (Ubuntu) getestet. Wieder Abstürze, zwar nicht mehr so viele, ist aber dennoch unbefriedigend. Wie soll das denn auf dem Servermarkt funktionieren, da sind die Kernel noch älter und man kann auch nicht mal eben einen neuen einspielen. Oder eben mit anderen Distributionen, die nicht so schnell ein Upgrade durchziehen (z. B. Debian stable)?

Halte es für schwierig, hier von einem definitiven Software- oder Hardwareproblem zu reden. Nicht nur, da die Informationslage schlecht ist, sondern auch weil zu einem Problem immer zwei gehören. Man muss sich nicht wundern, dass die relativ große, ausführliche Cache-Infrastruktur des K10 (ich rede nicht von den Cachegrößen!) mit L3-Cache zur Synchronisierung der Kerne zu Problemen führt. Schließlich sind die Latenzen niedrig, das Tempo recht hoch und die Architektur neu.
Intel hatte vor kurzem auch Probleme mit Datenkorruption am FSB durch ähnliche Faktoren. Dass ähnliches auch beim Nehalem und anderen zukünftigen Produkten (unabhängig vom Hersteller) passiert, ist wahrscheinlich.

 

[Situationskomik]

Da hast du mich vermutlich falsch verstanden. Ich hatte ja schon erwähnt, dass das Problem vielfältige Ursachen haben kann. Meine Aussage bezog sich vielmehr auf Situationskomik, und dass wenn man erstmal CPU und OS als Ursache in Betracht zieht, das OS wahrscheinlicher ist.

dein win95-beispiel war aber ab einer gewissen taktfrequenz ein prinzipielles problem - jeder amd-prozessor hat da zu dem timingproblem geführt.

die lage jetzt ist aber mE anders. nur einige cpus verursachen das problem. wenn es nur einige sind, dann müsste ja die software auf identische cpus, die fehlerfrei sind, anders reagieren.
andersherum: wenn es ein problem von vista64 wäre, warum gibt amd das nicht offen zu? das müsste doch ganz leicht reproduzierbar sein - mein rechner beispielsweise arbeitet @stock praktisch gar nicht. den phenom (und opteron-ableger) gibt es ja schon geraume zeit, da sollte es mich wundern, dass noch kein hotfix existiert. und damals gabs ein fix, das das softwareproblem beseitigte.

noch mal andersherum: ich habe aus spaß eine ubuntu64-live-cd ausprobiert - die startet mit der cpu@stock auch nicht bis zum desktop. also benutzt ubuntu dieselben bibliotheken wie ms mit denselben timingproblemen?

was für mich pro cpu-problem spricht:
bei 2ghz laufen vista64 und ubuntu64 problemlos.


weil ich ja nicht leichtfertig eine heile cpu zurückgeben will, habe ich memtest und prime95 laufen lassen (nochmals):
prime lief @2.0ghz über 2h problemlos - habs dann ausgemacht. bei 2.2ghz kam ich in vista wieder einmal nicht hinein.

memtest ließ ich ebenso 3h laufen - natürlich @2ghz, weil das andere ein glückstreffer wäre - problemlos.

 

[MacroWelle]

@Situationskomik
Wenn der Befehlssatz einer x86-CPU für dich "Bibliotheken" (im Sinne von analog zu Softwarelibs) sind, dann ja.

Ach ja, mit welcher Fehlermeldung stockte Ubuntu64?

Ansonsten gehe ich davon aus, dass die derzeitigen (Desktop-)Kernel schlicht Probleme mit dem Aufbau des K10 haben, die Fehlermeldungen deuten meiner Meinung nach auf Synchronisationsprobleme zwischen den Prozessorkernen hin, in Verbindung mit den Caches und den Latenzen (da die Probleme mit höheren Taktraten dichter auftreten).

 

[Nehebkau]

"Phenom 9500 @ 2.8 in M2n-SLI deluxe.

So I went head and started the experimentation. I started moving the Multi from 5.5 to 11 in all cores. Core 0 passed. no problems, Core 1 passed, no problems, Core 2 reached 11Multi and WHAM! BSOD. oh s**t... I... I got it!. rebooted the PC moved core 0,1 and 3 to 11Multi and everything passed and worked great I slowly moved core 2 to as high as I could before BSOD and I could only get it to 2.05Ghz stable..."

Naja der Multi war bei 11... wer muss denn den Multi so hoch einstellen?? für mich hat so ein "bug" falls es ihn wirklich gibt (und nur in solchen fällen auftritt) keine Bedeutung... hört sich alles sehr übertrieben an für mich, wie bem TLB-Bug. Ist bei jemandem den ihr kennt oder bei euch selbst mal der PC abgestürzt (oder wie immer) wegen dem bug??

 

[Schugy]

Ein Quadcore ist eben nur so schnell wie sein schwächster Core und wenn der Standardtakt 5 - 10% unter der BSOD-Schwelle liegt, dann ist das ok. Andersherum sollte man das Ding einfach umtauschen - das ist aber kein Architektur-Bug.

 

[Situationskomik]

Naja der Multi war bei 11... wer muss denn den Multi so hoch einstellen?? für mich hat so ein "bug" falls es ihn wirklich gibt (und nur in solchen fällen auftritt) keine Bedeutung... hört sich alles sehr übertrieben an für mich, wie bem TLB-Bug. Ist bei jemandem den ihr kennt oder bei euch selbst mal der PC abgestürzt (oder wie immer) wegen dem bug??

der standardmulti beim phenom 9500 ist 11. natürlich "muss" ich den teiler nicht so hoch stellen, aber ich habe über 300mark dafür ausgegeben, dass die cpu damit auch läuft.
und ja: mein rechner stürzt permanent ab bei standardtakt.

hoffentlich bald nicht mehr, eine ersatz-cpu ist auf dem weg.

 

[gruffi]

dein win95-beispiel war aber ab einer gewissen taktfrequenz ein prinzipielles problem - jeder amd-prozessor hat da zu dem timingproblem geführt.

Nein, das hatte mit Taktfrequenz nichts zu tun. Das war ein generelles Problem einer Instruktion.

die lage jetzt ist aber mE anders.

Das ist richtig. Das Beispiel sollte aber auch nur dazu dienen, zu zeigen, dass auch das Betriebssystem die Ursache für Probleme sein kann. Es ging nicht darum, einen konkreten Bezug herzustellen.

andersherum: wenn es ein problem von vista64 wäre, warum gibt amd das nicht offen zu?

Woher soll AMD denn wissen, ob Vista64 das Problem ist? Ich denke nicht, dass sie Einblick in den Quellcode haben. Geschweige denn, einfach mal ein paar Debug Sessions zu machen.

das müsste doch ganz leicht reproduzierbar sein

Oha, da hast du aber eine wahnwitzig naive Vorstellung. Software kann so ziemlich das komplizierteste überhaupt sein.

noch mal andersherum: ich habe aus spaß eine ubuntu64-live-cd ausprobiert - die startet mit der cpu@stock auch nicht bis zum desktop.

Ubuntu ist für den Phenom afaik erst ab einer bestimmten Kernel Version freigegeben. Hier notfalls einfach mal aktualisieren.

Es kann durchaus möglich sein, dass bei dir tatsächlich ein Hardware Fehler vorliegt. Aber wie bereits erwähnt wurde, das kann unterschiedliche Ursachen haben, zB in Verbindung mit RAM und Mainboard. Die CPU kann man natürlich nie ausschliessen, ist idR aber das unwahrscheinlichste.
Kannst du die Kerne im BIOS eigentlich deaktivieren? Wenn ja, dann teste mal jeden einzeln beim Booten.

 

[MountWalker]

Nein, das hatte mit Taktfrequenz nichts zu tun. Das war ein generelles Problem einer Instruktion....

Windows 95 verwendete einen Loopprozess mit Durchlaufmenge = n um beim Systemstart Zeit zum Initialisieren der Hardware zu lassen, diese Menge konnte zwar nur zu schnell berechnet werden, weil Loop im K6-2 ohne Decoder, fest verdrahtet berechnet wurde (anders, als bei allen vorrangegangenen X86), aber die Berechnung der Loopschleife war trotzdem erst ab 350 MHz zu schnell, ein K6-2 300 konnte Win95 auch ohne Patch erfolgreich starten - insofern spielte die Frequenz auch eine (wenn auch untergeordnete) Rolle.

 

[Tulol]

@ 49) Eusterw

Intel hat aber sehr lange gebraucht um fest zu stellen das der Pentium4 totaler mist war^^
Übrigens hat Intel damit auch gezeigt daß sie mit ihrem dicken finanziellen Polster solche Pannen auch mit Gewalt noch gut verkaufen können.

Was den Fehler im Phenom angeht, er IST vernachlässigbar. Ich verstehe ehrlichgesagt nicht wieso jetzt so ein Trubel darum gemacht wird. Dem 0815 user wird diese 'macke' nie(!) auffallen.
0815 User sind in dem fall alle die den Fehler nicht absichtlich versuchen zu reproduzieren.

 

[Situationskomik]

update:
heute morgen ist mein ersatz-phenom angekommen.
der läuft jetzt den halben tag ohne einen bsod im standardtakt - also im bios alles auf auto.

vorhin habe ich aus jux mal kurz übertaktet, da reagierte das bios sogar noch beim ref-takt von 210 und sogar bei 220. mit ref-takt von 220 bootete sogar vista und es ließen sich programme starten.
jetzt bin ich wieder bei "auto" und noch läuft alles...

wenn das ein vista-problem ist, dann ist es aber offensichtlich cpu-abhängig.

falls vista jetzt mehrere tage damit läuft, werde ich mich wieder melden.