AMD - Ryzen "Compiler-Bug" [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : AMD - Ryzen "Compiler-Bug"

aufkrawall

2017-07-18, 19:00:53

Gorkon

2017-07-18, 19:28:38

Warum gibt es dann keine solchen Meldungen von Windows-Usern? Nix, nada. Kompilieren kann ich da auch. Ich wäre wirklich vorsichtig mit solchen Aussagen, ohne wirklich handfeste Beweise. GCC ist auch nicht gerade ohne, wenn es um Fehler geht > https://www.golem.de/news/betriebssysteme-fehler-im-linux-kernel-wegen-gcc-1407-108153.html
Das betraf auch unter anderem damals Cyanogenmod 11, was sich durch ähnliche Fehler nur mit älteren GCC-Versionen kompilieren ließ.

Anyway...Ryzen-Nutzer können ja mal das hier runterladen und ausführen: https://github.com/hayamdk/ryzen_segv_test/releases

Kommt auch aus dem Gentoo-Forum und ist ein kleines Testprogramm um den Fehler zu provozieren. Ich probiers die Tage bei der Holden auch mal aus...

EDIT: Und btw. Krawalli: Wenn du schon sagst man sollte sich mal den Thread durchlesen, wäre dir das Tool auch aufgefallen > Hättest du dann auch posten können. So verkommt der Post irgendwie leicht zu nem Bashing-Zweizeiler ;)

mfg

aufkrawall

2017-07-18, 19:36:01

Warum gibt es dann keine solchen Meldungen von Windows-Usern? Nix, nada. Kompilieren kann ich da auch.

Das tut offenbar überhaupt nichts zur Sache. Den Ryzen HTT-Fehler gab es auch nur unter Windows, den letzten von Intel offenbar nur unter Linux.

Ich wäre wirklich vorsichtig mit solchen Aussagen, ohne wirklich handfeste Beweise.

Rat mal, warum ich das Wort "womöglich" verwendet habe. Im Übrigen könntest du auch vorsichtiger sein mit dem Verkünden von vermeintlichen erfolgreichen Workarounds wie Low LatencyEchtzeit-Kernel. Paar Tage/Wochen abwarten und so.

GCC ist auch nicht gerade ohne, wenn es um Fehler geht > https://www.golem.de/news/betriebssysteme-fehler-im-linux-kernel-wegen-gcc-1407-108153.html
Das betraf auch unter anderem damals Cyanogenmod 11, was sich durch ähnliche Fehler nur mit älteren GCC-Versionen kompilieren ließ.

Ja, ja. Clang ist auch betroffen...

sun-man

2017-07-18, 19:46:35

Gorkon

2017-07-18, 20:14:38

@aufkrawall

Ok, dass "definiitv" im damaligen Post ist hinfällig, wenn man dem Thema im AMD-Forum folgt. Zurecht recht ;)

Trotzdem...ohne Biased zu sein / werden: Das Problem ist soooooo fischig, dass ich da bei meiner Aussage bleibe: Ohne Handfeste Beweise zu vermuten, die Chips sind kaputt, ist abenteuerlich. Genauso meine Vermutung LL-Kernel helfe...

Bei einigen hilft AGESA 1.0.0.6a, bei anderen Linux 4.11.7 - .9, ab 4.12 crasht es wieder, weil wohl global KASLR gesetzt wird, etc. etc.

Ich glaube man sollte da eher die Füße stillhalten und abwarten ob Epyc (B2) auch Probleme hat oder nicht...oder ob nochmal ein neues AGESA kommt was evtl. einen Fix ähnlich dem Workaround von dem Dragonfly-Entwickler enthält. Da habe ich jedenfalls bisher nix mehr von dem Fehler gelesen...

EDIT: Noch ne "Option" *sigh* > https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads/page14

SavageX

2017-07-18, 20:29:09

Ich beobachte diese GCC segfault Geschichte nun seit einiger Zeit. Für mich war fest ein Ryzen 1700 geplant, das pausiere ich erstmal, drängt mich ja nichts. Es ist aktuell unklar, was da passiert, aber einige Benutzer scheinen doch arge Schwierigkeiten zu haben, ihre Kisten stabil zu kriegen. Argumente wie "benutzt ja eh keiner GCC" greifen für mich nicht - ein Prozessor muss nach Möglichkeit alle halbwegs vernünftigen Programme fehlerfrei ausführen können, auch unter hohem Stress (synthetische Codesequenzen, die absichtlich konstruiert wurden, um bestimmte Fehler zu provozieren, lasse ich mal außen vor - jede CPU hat Fehler).

Da unklar ist, was da los ist (schlampige Mainboards? Inkompatibler RAM? Designfehler im B1-Stepping? Test-Escapes beim Binning?) und wie der Fix aussieht, beobachte das Ganze mal ganz entspannt. Epyc kommt ja im B2-Stepping - da kann man sich abschmierende Compiler nicht leisten. Vielleicht ist ja Agesa 1.0.0.6a genau ein Hotfix dafür.

sun-man

2017-07-18, 20:32:03

Genau das ist doch der Punkt. Es ist nicht klar was dazu führt. Die Frage wäre ja eher ob und was AMD tut.

aufkrawall

2017-07-18, 20:32:42

Ich hatte allerdings keine Stabilitätsprobleme mit dem ganzen System, sondern das Kompilieren brach zufällig einfach durch Segfault ab. Sowohl mit GCC als auch Clang.

Ätznatron

2017-07-18, 20:41:08

Argumente wie "benutzt ja eh keiner GCC" greifen für mich nicht - ein Prozessor muss nach Möglichkeit alle halbwegs vernünftigen Programme fehlerfrei ausführen können, auch unter hohem Stress (synthetische Codesequenzen, die absichtlich konstruiert wurden, um bestimmte Fehler zu provozieren, lasse ich mal außen vor - jede CPU hat Fehler).

Sehe ich nicht so.

Ein Programm muss so gestaltet sein, dass es halbwegs fehlerfrei auf einem gegebenen Prozessor ausgeführt werden kann.

SavageX

2017-07-18, 20:42:55

Genau das ist doch der Punkt. Es ist nicht klar was dazu führt. Die Frage wäre ja eher ob und was AMD tut.

Jup, und bisher kommunizieren die sehr wenig. Eine Aussage "ist bekannt, AGESA-Fix kommt bald" oder "Mainboard/RAM passen nicht" würden mir ja schon reichen. Dass jedoch bei einigen Benutzern wohl Machine Check Exceptions fliegen, die auf fehlerhafte Prüfsummen im µOP-Cache hindeuten, spricht eher dafür, dass sich die CPU ziemlich verbasselt.

Mal schauen, was AMD da macht.

SavageX

2017-07-18, 20:47:20

Sehe ich nicht so.

Ein Programm muss so gestaltet sein, dass es halbwegs fehlerfrei auf einem gegebenen Prozessor ausgeführt werden kann.

Wenn ein Prozessor ein Programm nicht fehlerfrei ausführen kann, jedoch ein Intel Celeron/Pentium/i3/i5/i7 oder ein AMD K8/K10/Bulldozer/Bobcat/Jaguar denselben Code problemlos abarbeitet, dann ist das ein Problem im neuen Prozessor. Alte Programme müssen laufen, sonst ist da ein Kompatibilitätsproblem - zumal ja die meisten Benutzer nicht eben mal den Compiler anwerfen kann, um "entschärften" Code zu erzeugen.

edit: Mir geht es übrigens nicht drum, da jetzt einen schwerwiegenden und unbehebbaren Fehler im Ryzen zu postulieren.

Ätznatron

2017-07-18, 20:58:54

Wenn ein Prozessor ein Programm nicht fehlerfrei ausführen kann, jedoch ein Intel Celeron/Pentium/i3/i5/i7 oder ein AMD K8/K10/Bulldozer/Bobcat/Jaguar denselben Code problemlos abarbeitet, dann ist das ein Problem im neuen Prozessor. Alte Programme müssen laufen, sonst ist da ein Kompatibilitätsproblem - zumal ja die meisten Benutzer nicht eben mal den Compiler anwerfen kann, um "entschärften" Code zu erzeugen.

edit: Mir geht es übrigens nicht drum, da jetzt einen schwerwiegenden und unbehebbaren Fehler im Ryzen zu postulieren.

Ebenso kann man behaupten, dass es lange gut gegangen ist. ;)

Solange es kein Massenphänomen ist, sondern Sache einer Handvoll User, denke ich, dass es eher ein User-Problem ist und weniger eines der Hardware.

SavageX

2017-07-18, 21:08:05

Ebenso kann man behaupten, dass es lange gut gegangen ist. ;)

Solange es kein Massenphänomen ist, sondern Sache einer Handvoll User, denke ich, dass es eher ein User-Problem ist und weniger eines der Hardware.

Ja, mal schauen, was sich da entwickelt. Die c't konnte den Fehler bisher bei ihrem Ryzen-Bauvorschlag nicht nachstellen. Das mag darauf hindeuten, dass es kein prinzipielles Problem im Design ist, sondern "das Zeug drumherum" oder dass ein paar kaputte Exemplare es durch die Tests bei der Fertigung geschafft haben.

aufkrawall

2017-07-18, 21:22:07

Solange es kein Massenphänomen ist, sondern Sache einer Handvoll User, denke ich, dass es eher ein User-Problem ist und weniger eines der Hardware.
Was soll denn ein "User-Problem" sein? :freak:

Gorkon

2017-07-18, 21:26:49

Evtl. sollten die Betroffenen das Stepping angeben (so 200x X-D). Beschreibungen der sonstigen Hardware ist bei den meisten Leuten da leicht...dürftig.

mfg

Ätznatron

2017-07-18, 21:39:25

Was soll denn ein "User-Problem" sein? :freak:

Ich bitte Dich!

Eine völlig vergurkte Entwicklungsumgebung zum Bleistift.

aufkrawall

2017-07-18, 21:42:31

Ich bitte Dich!

Eine völlig vergurkte Entwicklungsumgebung zum Bleistift.
Dann gibt der Compiler keine Segfaults als Warnung raus.
Entweder, der Kram kompiliert mit den gesetzten Flags, oder halt nicht. Nix Grauzone, nix "manchmal".

Ätznatron

2017-07-18, 21:47:03

Dann gibt der Compiler keine Segfaults als Warnung raus.
Entweder, der Kram kompiliert mit den gesetzten Flags, oder halt nicht. Nix Grauzone, nix "manchmal".

Und welche Schlüsse ziehst du daraus? Dass es allgemeingültig ist?

aufkrawall

2017-07-18, 21:53:53

Und welche Schlüsse ziehst du daraus? Dass es allgemeingültig ist?
Es erscheint mir derzeit am plausibelsten, dass es sich über die Zeit erhärten wird, dass manche Ryzens den Bug in Hardware haben und andere nicht. Aber da muss man Leute mit funktionierender RMA-CPU in ein paar Wochen/Monaten nochmal fragen. Menschen irren sich, aber Gentoo-Nutzer sind schon nicht gerade blöd.
Oder jemand macht einen großen Test mit 10-20 CPUs und ändert ansonsten nichts am System. Wenn dann einige CPUs das Problem aufweisen und andere nicht, wärs auch klar.
Ist aber halt teuer und aufwändig.

Ätznatron

2017-07-18, 22:06:12

Menschen irren sich, aber Gentoo-Nutzer sind schon nicht gerade blöd.

Gentoo-User können zwar blöd sein, müssen es aber nicht. Es war nie meine Absicht, jemanden für blöd zu erklären. Sorry, falls das so rübergekommen sein sollte.

StefanV

2017-07-19, 05:14:40

Es ist aktuell unklar, was da passiert, aber einige Benutzer scheinen doch arge Schwierigkeiten zu haben, ihre Kisten stabil zu kriegen.
Genau das ist doch der Punkt!
Und so lang man nicht weiß, was denn nun genau die Ursache ist, sollte man echt die Füße still halten!!

Einerseits besticht "Linux" nicht immer durch überragende Code Qualität sondern z.T. eher Intrigen, zum anderen ist ja nicht mal klar, wer denn nun die Sache wirklich verbockt hat!!

Aber schon interessant, dass einige Herrschaften den Intel SMT Bug verschweigen aber bei AMD in diesem Falle drauf knüppeln...

Die c't konnte den Fehler bisher bei ihrem Ryzen-Bauvorschlag nicht nachstellen. Das mag darauf hindeuten, dass es kein prinzipielles Problem im Design ist, sondern "das Zeug drumherum" oder dass ein paar kaputte Exemplare es durch die Tests bei der Fertigung geschafft haben.

Das deutet darauf hin, dass die User, die dieses Problem entweder ein kaputtes System haben oder irgendwas bei dem, was sie sonst verwenden, ziemlich im Klo ist. Oder das System nur scheinstabil, aber nicht wirklich.

Generell sollte man bei Problemen mit Linux den Ball ganz flach halten!
Denn man weiß nie, ob das jetzt an der Hardware oder der Software ist.

Ein Beispiel von mir:
Viele Linux Distributionen laufen bei mir auf meinen Intel Notebooks nicht sinnvoll.
Besser gesagt schalten die beim booten einfach die Kiste aus!
Das ganze tritt bei 2 Dell (P965, Sockel P), 1 Acer (i940GML, Sockel M) und dem Medion (Pentium M, i855GM) auf.
Da kann mir niemand sagen, dass das NICHT an den Programmen liegt. Dass das an der Hardware liegt, ist bei der schieren Anzahl an Geräten und der breite der Teile einfach mal völlig ausgeschlossen...

Wenn ein Prozessor ein Programm nicht fehlerfrei ausführen kann, jedoch ein Intel Celeron/Pentium/i3/i5/i7 oder ein AMD K8/K10/Bulldozer/Bobcat/Jaguar denselben Code problemlos abarbeitet, dann ist das ein Problem im neuen Prozessor.
So wie Windows 95 auf K6, später Pentium II/III??
Also sind alle Coppermine Pentium3 kaputt, weil die dieses Programm nicht ausführen können.

Oder ein Wing Commander I/II auf 'nem Pentium. Das läuft ja auch nicht wirklich. Das muss laut dir ja alles am Prozessor liegen, nicht wahr? ;-)

SavageX

2017-07-19, 07:04:43

Genau das ist doch der Punkt!
Und so lang man nicht weiß, was denn nun genau die Ursache ist, sollte man echt die Füße still halten!!

Einerseits besticht "Linux" nicht immer durch überragende Code Qualität sondern z.T. eher Intrigen, zum anderen ist ja nicht mal klar, wer denn nun die Sache wirklich verbockt hat!!

Ist da noch ein technisches Argument drin?

Wenn Dir der Linux-Kernel nicht gefällt: Dasselbe Problem wurde auch unterm Windows-Kernel nachgestellt - da kann man ja seit neuestem dieselben Binaries laufen lassen.

Auch BSD-Entwickler haben schon setlsames Verhalten gesehen: https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads?p=955498#post955498

Hier sogar ein Workaround-Patch: http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/b48dd28447fc8ef62fbc963accd301557fd9ac20

Aber schon interessant, dass einige Herrschaften den Intel SMT Bug verschweigen aber bei AMD in diesem Falle drauf knüppeln...

Hmm? Wo wird denn hier draufgeknüppelt? Ist irgendwie auch der falsche Thread, um auf den Skylake-HT Bug zu hauen. Zumindest ist da auch klar, wie der Fix aussieht.

Das deutet darauf hin, dass die User, die dieses Problem entweder ein kaputtes System haben oder irgendwas bei dem, was sie sonst verwenden, ziemlich im Klo ist. Oder das System nur scheinstabil, aber nicht wirklich.

Na, es gibt schon genug Kisten, auf denen man auch mal tagelang hintereinander ein größeres Software-Projekt durchkompilieren kann - so wie es sein soll.

Generell sollte man bei Problemen mit Linux den Ball ganz flach halten!
Denn man weiß nie, ob das jetzt an der Hardware oder der Software ist.

Ein Beispiel von mir:
Viele Linux Distributionen laufen bei mir auf meinen Intel Notebooks nicht sinnvoll.
Besser gesagt schalten die beim booten einfach die Kiste aus!
Das ganze tritt bei 2 Dell (P965, Sockel P), 1 Acer (i940GML, Sockel M) und dem Medion (Pentium M, i855GM) auf.
Da kann mir niemand sagen, dass das NICHT an den Programmen liegt. Dass das an der Hardware liegt, ist bei der schieren Anzahl an Geräten und der breite der Teile einfach mal völlig ausgeschlossen...

Klingt nach einer gänzlich anderen Klasse von Problemen.

So wie Windows 95 auf K6, später Pentium II/III??
Also sind alle Coppermine Pentium3 kaputt, weil die dieses Programm nicht ausführen können.

Das war schnell debuggt: Schlampige Timing-Schleife, die bei schnellen Prozessoren zu schnell durchlief. Hier wurde der Maschinencode genau so ausgeführt, wie der da stand, absolut deterministisch.

Oder ein Wing Commander I/II auf 'nem Pentium. Das läuft ja auch nicht wirklich. Das muss laut dir ja alles am Prozessor liegen, nicht wahr? ;-)

Wing Commander I/II laufen auf einem Pentium (oder noch schnelleren Kisten) genau so, wie der Maschinencode es sagt. Bei zu schnellen CPUs halt schneller als beabsichtigt, aber ein Computer soll ja das machen, was man ihm sagt - und nicht das, was der Programmierer eigentlich wollte ;)

Problematisch - und um diese Klasse von Fehlern geht es hier - sind Fälle, in denen Maschinencode "manchmal" halt nicht das tut, was er soll. Wenn das Problem unter mehreren Betriebssystemen auftritt (check) liegt da schon nahe zu vermuten, dass *irgendwas* auf Seiten der Hardware da schräg läuft. Das muss nicht zwangsläufig der Prozessor selbst sein.

Ätznatron

2017-07-19, 09:09:21

Wer einen Ryzen besitzt, kann sich ja mal ans Kompilieren machen und dann schauen was passiert:

https://github.com/hayamdk/ryzen_segv_test/blob/master/ryzen_segv_test.c

Conner_Ray

2017-07-19, 10:54:24

Daedalus

2017-07-19, 11:54:21

SavageX

2017-07-19, 17:54:07

Ich habe den Ryzen SEGV-Test mal unter Win 10, mit den vorgeschlagenen Werten (n = 8, m = 2500000), laufen lassen. @Stock und RAM @2133 MHz bekomme ich nach einigen hundert Iterationen (400-500) Segfaults. Mit RAM @3200 MHz und SoC Voltage bei ~1,05V braucht es dann schon 2000 - 3000 Iterationen bis Segfaults auftreten. Werde heute Abend weiter mit höherer SoC Voltage testen.

System:
Ryzen 7 1700, Asus Prime X370 Pro, 16GB G.Skill Trident-Z 3200 CL14

Mich würde mal interessieren, ob die "wackelige" Konfiguration stabiler wird, wenn man SMT abschaltet... und natürlich, ob das Testprogramm auf einem Intel-Prozessor oder einem AMD FX stabil ist...

aufkrawall

2017-07-19, 17:59:27

Habe 3000 Loops ohne Fehler mit dem 6700k unter Windows durchlaufen.
Scheint trotz des niedrigen Stromverbrauchs aber extrem allergisch auf instabiles OC zu reagieren. Außerdem wird das System quasi gelähmt und denkt deshalb offenbar, der Grafiktreiber würde nicht mehr reagieren und startet ihn manchmal neu. Wenn einen das nervt, sollte man so lange den Treiber abschalten (Gerät im Gerätemanager abschalten).

SavageX

2017-07-19, 18:23:40

Eine Frage als Linux-Laie, was passiert denn Unterschiedliches im Prozessor wenn ich was kompiliere? Im gegensatz zu einen "ausführen" eines Programms? Also warum ist gerade das Kompilieren so heikel?

Compiler machen eigentlich mit der CPU keine Schweinereien, die andere Programme nicht machen würden. Allerdings können Compiler viel Stress erzeugen - alle Kerne auslasten, viel im Speicher rumwühlen, viel herumspringen.

Ganon

2017-07-19, 19:09:02

Eine Frage als Linux-Laie, was passiert denn Unterschiedliches im Prozessor wenn ich was kompiliere? Im gegensatz zu einen "ausführen" eines Programms? Also warum ist gerade das Kompilieren so heikel?

Compiler sind sehr I/O-Internsiv. Sie lesen Daten vom Datenträger, rechnen auf allen Kernen Zeug durch, schieben große Mengen Daten im RAM umher, schreiben das wieder auf die Platte usw. usw.

Das ist sowohl für die CPU, als auch für das Betriebssystem sehr aufwändig. Zeug kompilieren war schon immer ein ziemlich guter Stabilitätstest.

Isen

2017-07-19, 19:10:56

Wenn die 2500000 durch sind und OK ist alles jut, oder woran Erkenne ich hier jetzt diesen angeblichen Bug?
Ding läuft ohne irgendwelche zicken rum @#27 (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11434761&postcount=27), surfe jetzt einfach mal weiter und lass das mal Rödeln, mach dann zum Schluss nen Screen, Hardware und OC stehen eh inne Sig.

iuno

2017-07-19, 19:18:06

Ich bin jetzt bei 2500 und hatte noch keinen Fehler. Bin spaeter nochmal weg und lasse es weiterlaufen, mal schauen, was passiert.
@Isen: Du musst im log schauen, ob es ein Problem gab. Die Schleife wird nicht abgebrochen
z.B.
grep "NG" log.txt
oder waehrend es noch laeuft
tail -f log.txt | grep "NG"
Dort wo du es startest solltest du aber auch eine Rueckmeldung bekommen wenn es einen segfault gibt.

Isen

2017-07-19, 19:27:32

achso, ja, danke dir.
Zeigt es ja Aktuell an 1000 OK | ng: 0 | others: 0
und im Log steht überall OK - bis auf die Log.txt und Readme.txt ist da ansonsten nix mehr.
Ich koche jetzt erstmal essen und lass es weiterlaufen. Wenn es die [m] Settings bzw. Loops durchlaufen hat, also nix Bug, woll?

aufkrawall

2017-07-19, 19:40:13

Annahmen aufgrund dieses Tests sind offenbar die besten, die man derzeit machen kann, sofern man nicht unter Linux "echt" kompilieren will.

Das Teil ist einfach heftig: Weder Cache-OC von 4,1 auf 4,2GHz bei Auto-Spannung sind hier stabil, noch Default-Cachetakt bei -30mV Vcore (4,2GHz Allcore-Kerntakt). Das lief beides zusammen mit Prime95 stabil bei längerer Laufzeit. :freak:

Isen

2017-07-19, 19:41:58

Noja... wenn das ohne Muxen durchläuft, ist mein OC und rumgefummel am Speicher ja prächtig geworden :-D
Bin jetzt bei 2800 ng: 0 - others: 0

Die das Problem haben, sollen mal die PLL Voltage auf 1,85v erhöhen, hilft das bereits mehr Loops zu schaffen als vorher, dann halt 1,9v.
Das Setting macht Speicher und CPU OC nochmals stabiler. Wenn das nämlich zu stark schwankt, ist das NT bzw. Board fürn Arsch. Also nicht AUTO lassen.
Das wäre jetzt mein Tipp.

gravitationsfeld

2017-07-19, 20:16:50

Isen

2017-07-19, 20:33:06

Meine Meinung: AMD scheint es nicht an die grosse Glocke haengen zu wollen, wahrscheinlich weil es nicht mit Microcode-Updates loesbar ist und es eine PR-Katastrophe waere.

Die, die das Problem haben oder den Stein da anrollen wollen, haben ihre System übertaktet? (Kurz mal drüber geschielt, und ja, überall OC)
Wie schaut es bei denjenigen aus, wenn alles auf Stock läuft?

Ich hab ehrlich gesagt jetzt nicht die Muße mir das dort alles rein zu ziehen, aber da du ja offensichtlich dem Thema vertraut bist, wär nett, wenn du mir da den fehlenden Überblick geben könntest.

Edit: Gleich bei 5000 noch immer kein ng.

aufkrawall

2017-07-19, 20:33:51

Soll auch mit alles@stock auftreten.

Isen

2017-07-19, 20:37:27

Hm... hat wer nen Account dort?
PLL Voltage Manuell auf 1,80v fixen, hilft das, ok, wenn nicht 1,85v bis max 1,90v - hilft das, lässt sich das Problem deutlicher eingrenzen.
Wenn es das Problem quasi behebt, schwankt der von AMD angegebene Wert zu sehr, und somit ein Board Problem, oder wurde von AMD zu tief angesetzt, was mittels Bios zu beheben kein Problem darstellt. Was zum Problem wird ist die Temperatur, die steigt recht heftig bei 1,90v - zwischen idle +10 bis load +15°c - je nach Kühlung wird das zum Problem, speziell bei den X Varianten, da dann jeder Lüfter sofort auf max aufjault

Edit: 6000 noch immer kein ng.

Conner_Ray

2017-07-19, 20:42:12

@ganon und savagex
Danke für die Erklärung. D.h es kann sowohl an der CPU, am Speicher oder auch HDD liegen dass es crasht? vor allem bei OC?
gab es das Problem auch mit einen nicht OC-system, weder Specier noch CPU OCed?

fondness

2017-07-19, 20:47:44

Die, die das Problem haben oder den Stein da anrollen wollen, haben ihre System übertaktet? (Kurz mal drüber geschielt, und ja, überall OC)
Wie schaut es bei denjenigen aus, wenn alles auf Stock läuft?

Ich hab ehrlich gesagt jetzt nicht die Muße mir das dort alles rein zu ziehen, aber da du ja offensichtlich dem Thema vertraut bist, wär nett, wenn du mir da den fehlenden Überblick geben könntest.

Edit: Gleich bei 5000 noch immer kein ng.

War auch mein erster Gedanke.

Isen

2017-07-19, 21:24:04

Noch immer kein ng.
Nur 75% last... ich zock jetzt trotzdem ne Runde LoL, muss die CPU abkönnen, kein bock mehr auf Surfen.

Edit:

Hab das jetzt mal abgebrochen... 2 Runden LoL nebenher gezockt.. kein ng lief also über 3 Stunden.

Hab jetzt mal meinen Speicher OC auf Stock geknallt, und nur CPU OC belassen. Gleich nach 2min kam sofort ng.
Habe dann die Spannung erhöht auf 1,400v - sofort wieder ng, sogar gleich mehrfach.
Dann den Takt um 100mhz reduziert, also 3,8Ghz bei 1,400v auch hier wieder sofort mehrfach ng.
Die PLL Voltage mal auf 1,80v fixiert - und den CPU OC wieder hinzugezogen (3,9Ghz @1,375v) +2000 Loops und 1 ng.
Mach ich PLL Voltage auf AUTO sofort Fehler innerhalb 2min. (AUTO = 1,80v)
Schalte ich meinen Speicher OC hinzu erhöhe aber die PLL Voltage nicht auf 1,85v sofort Fehler!
Habe jetzt die PLL Voltage auf 1,80v fixiert inkl. meinem CPU OC aber ohne meinen Speicher OC und das rennt jetzt auch bei 1000 und > 1 ng.

Edit: Jetzt stell ich mal alles auf Stock... mal sehen.
Edit: Haha... alles auf Stock, Multiplier x30 - 3000Mhz eben - kaum in Windows: Multiplier auf x32 3200 Mhz O_o... zurück ins Bios, Bios komplett zurückgesetzt. Wieder ins Windoof > wieder x32 3200Mhz... wtf :D?
Naja... ich lass mal rödeln.
Edit: Wie auf Stichwort, bei 650 gab es 1 ng.

Aktuell am laufen ohne Fehler:

-Alles auf Default bzw. AUTO - Bis auf Speicher: 3466 @CL14 und meine Hand Optimierten Timings @ 1,400v und Boot Voltage 1,400v - AMD CBS: BGS & GDM Disabled
-Kuriose bleibt aber weiterhin, dass mein Board auf AUTO Multiplier = x30 in Windows dann x32 werden... also 3,2Ghz ...

Alles auf Stock > Fehler.
CPU OC und Speicher Stock > Fehler
CPU OC und Speicher OC > Läuft ( nach über 3h abgebrochen, währenddessen sogar gezockt)
CPU Stock und Speicher OC > Läuft noch ohne Fehler @11200 um 01:50 Uhr 2017/07/20 02:55:59 18626: NG(-1073741819)
CPU Stock und Speicher Stock Spannung wie beim OC > Fehler
CPU Stock und Speicher Stock mit PLL auf AUTO, 1,80v fixiert, 1,85v und 1,90v > Fehler
CPU Stock und Speicher Stock mit OC Voltages mit PLL auf AUTO, 1,80v fixiert, 1,85, 1,90v > Fehler

Offensichtlich beeinflusst bei mir der Speicher OC das ganze geschehen. Sobald ich den auf Stock betreibe, wie er laufen sollte, ist es egal was ich anderes einstelle, es läuft nicht.
Nur mit Speicher OC und meinen Timings läuft es.
IMC ein knick weg?
Bios ein an der Waffel?

Kann sich da wer nen Reim drauf machen?

iuno

2017-07-20, 01:41:50

Wenn es die [m] Settings bzw. Loops durchlaufen hat, also nix Bug, woll?
Wenn das Tool keinen Fehler ausspuckt beweist das natuerlich erstmal gar nichts. Wenn sich herausstellt, dass es als Stabilitaetstest ganz gut taugt, kann man es schon als gutes Indiz werten. Bei mir waren es jetzt >25k Iterationen wo nichts passiert ist.

@aufkrawall: Mit welchem Workload hattest du Probleme?
Meine Meinung: AMD scheint es nicht an die grosse Glocke haengen zu wollen, wahrscheinlich weil es nicht mit Microcode-Updates loesbar ist und es eine PR-Katastrophe waere.
Fraglich, ob es nicht noch katastrophaler wird, wenn man reproduzierbar Faelle findet, wo es kracht, und es dann so im Detail bekannt wird, bevor AMD irgendwas machen kann.

aufkrawall

2017-07-20, 02:39:05

@aufkrawall: Mit welchem Workload hattest du Probleme?

Es trat mit den pkgbuilds für linux-mainline und llvm-svn bei default flags und 16 Threads auf (aber nicht immer). Weniger Threads nicht getestet.

StefanV

2017-07-20, 04:25:52

Das ist ein Hardware-Bug, darueber braucht man nicht mehr rumdiskutieren.
Warum soll das der Fall sein?!
Warum verwendest du das Wort 'Bug', warum kann nicht einfach was kaputt sein??

Oder es einfach Wechselwirkungen mit anderen Komponenten gibt, die z.T. auf dem Board verbaut sind?
Ist ja nicht das erste mal, dass MoBo Hersteller durch ihr Tuning etwas kaputt machen, was vorher halbwegs brauchbar lief...

Dass das bei einigen auftritt und bei anderen nicht, deutet auch darauf hin, dass das irgendwas in diese Richtung sein könnte und nicht muss...

Achill

2017-07-20, 08:41:26

[..]
Wenn manche Dies nicht betroffen sind, ist es wohl eine unwahrscheinliche Race-Condition im Prozessor.

Das macht kein Sinn solange es nicht unterschiedliche Steppings eines Prozessors gibt.

Die anderen Erklärungen klingen plausibel, dass es ein Zusammenspiel aus CPU, MB, RAM sowie NT ist und es zu Spannungsschwankungen kommt, die - je nach Güte / Glück bei der CPU, MB, RAM - das eine System betroffen machen und ein anderes nicht.

StefanV

2017-07-20, 13:20:57

Einfach mal hier Seite 9 durchlesen:
https://forums.gentoo.org/viewtopic-t-1061546-postdays-0-postorder-asc-start-200.html?sid=4f8fc551a0b764a6ecb3d9cb7f19e028
Compiler-Bug ist immer noch nicht gelöst. Kein Workaround hilft bei jedem. Bei einigen brachte eine RMA Besserung -> AMD verkauft womöglich kaputte Chips...
Boh, was sind das da für Leute?!
Die sind nicht mal in der Lage 'ne vernünftige System Konfiguration anzugeben. Alles, was die da machen ist rumheulen, hilfreich ist das NULL.
Ohne exakte Angabe der Konfiguration ist jegliche Aussage zu diesem Thema einfach nicht möglich...

Hast du schon mal davon gehört, dass eine Festplatte ein Netzteil zum pfeifen bringt??
Ich schon. Und auch schon selbst gehört. Oder dass ein System reproduzierbar abschmiert/rebootet, wenn man bei einem bestimmten Netzteil eine einzelne GF100 basierte Karte an einem Board von einem bestimmten Hersteller betreibt...
Betreibt man genau diese Grafikkarte an einem Board von einem anderen Hersteller -> 0 Problemo.

Oder dass 'nen externes HDD Gehäuse dir Startprobleme beschert? (weil Spannung am USB anliegt).

Genau _DESWEGEN_ ist es, wenn man ein Problem hat, die Hardware ins kleinste Detail zu erwähnen...
Und NUR wenn man das macht, ist man in der Lage, ein Muster in dem ganzen zu erkennen...

Aber genau DAS machen die Leute ja nicht. Da wird nur eine minimalste Configuration angegeben...
Und das ist dann so sinnvoll wie Fußpilz. Dann kann mans auch gleich lassen...

Dass ich mal Probleme mit 'nem Kaveri hatte, die extremst blöde nachzuvollziehen waren, daran hänge ich mich heute auch nicht auf. Und der Witz ist, dass ich die APU, mit der ich den Fehler hatte, noch heute nutze - ohne diesen Fehler.
Und das war, dass es in unregelmäßigen Abständen ein Schachbrettmuster aufm Schirm gab und das System anfing zu hängen. Hab mich dann entschlossen, das Board auszutauschen. Und was war. Es war der Übeltäter. Nach dem das Board getauscht wurde, alles in Ordnung...

Und genau das ist ja der Punkt. Die Herstellung von MoBos ist nicht einfach, wenn man da das Temperaturprofil verkackt kann man locker diese Fehler verursachen, von denen man hier spricht. Und das ganze ist auch der Tanz auf einem ganz schmalem Grad. Denn bäckt man das Board zu stark, killt man Komponenten. Backt man das Board nicht stark genug, gibts Probleme mit Lötstellen.

Anyway:
hier mal ein (Werbe?) Artikel zur Herstellung von Boards (http://www.pcgameshardware.de/Mainboard-Hardware-154107/Specials/Gigabyte-Fabrik-in-Nan-Ping-750229/galerie/42/).
Man sieht sehr schön, dass das Board zwei mal gelöget wird. Einmal via Reflow Technik für SMT Bauteile. Und danach darf das Board dann durchs Lötbad, um die durch Loch Komponenten zu verlöten...
Aber das ist schon 8 Jahre (eher mehr) her...

Anyway:
Wer auch immer diese Probleme hat, hat auch immer die Hardware bis ins kleinste Detail anzugeben. Ansonsten ist der nicht ernst zu nehmen. AUCH Netzteil und angeschlossene USB Komponenten.

Ätznatron

2017-07-20, 14:35:17

Es bricht wohl niemandem dabei ein Zacken aus der Krone, die benutzte Hardware so detailiert wie möglich zu beschreiben.

Je vollständiger, um so aussagekräftiger ist das Resultat.

aufkrawall

2017-07-20, 14:36:54

CPU, RAM, deren Settings und Agesa-Version sind wichtig. Der Rest aber wirklich nicht.

Ätznatron

2017-07-20, 14:38:16

Dir vielleicht nicht, anderen möglicherweise schon. Tu denen doch den kleinen Gefallen...;)

Isen

2017-07-20, 14:38:57

Meine HDD hab ich mal abgesteckt, Laufwerk abgesteckt, USB Kabel für meine E-Dampfe auch mal abgesteckt (da hängt immer meine E-Dampfe dran und nuckelt Strom) - Soundkarte auch mal abgesteckt, sowohl Kopfhörer, als auch die Lautsprecher.

Dran ist nur noch Board, CPU, RAM, Grafikkarte, System SSD (Samsung Evo 850) , 5 Lüfter, Pumpe (am Netzteil direkt)
Flowmeter und Temp. Sensor abgesteckt.

@ Stock nach 2min Segefaults.
Übertakte ich den ganzen Kram hält das 3 Stunden bis ca 20k.

@Stock alle Spannungen fixiert... brachte auch nüx.

@Stock aber alle Spannungen erhöht takt belassen brachte jetzt auch nichts.

aufkrawall

2017-07-20, 14:42:32

Übertakte ich den ganzen Kram hält das 3 Stunden bis ca 20k.

Also nach 20k auch noch keine Segfaults?

@Stock alle Spannungen fixiert... brachte auch nüx.
Sehr mysteriös. :redface:

Isen

2017-07-20, 14:45:34

Ne, doch... dann kommen Segefaults. +/- 10-20min ab 20k rum kommen dann Segefaults.

aufkrawall

2017-07-20, 14:48:56

Ah, "gut". Dann sollte man zur Sicherheit also wirklich lange laufen lassen, :up: für deine Mühen.
Ich kann vorerst leider den Intel nicht so lange laufen lassen. Ich werd das aber machen das, sobald sich die Gelegenheit ergibt.

Edit: Dann wäre eine mögliche These, dass womöglich (!!!...) doch alle Ryzen-CPUs betroffen sind und bestimmte Konfigurationen das Auftreten einfach extrem selten werden lassen.

Isen

2017-07-20, 14:53:04

Kurios ist aber, sobald ich den Speicher übertakte, sei es jetzt auch nur die Spannung auf 1,400v läuft das bis ca 20k. Sobald dieser wieder @Stock läuft innerhalb 2min Segefaults.

Die komplette Phasenkontrolle die das C6H ja hat, für den Speicher, habe ich mal komplett deaktiviert, normal steht das von Asus auf " Extreme " ... selbe Bild > sobald ich da dran gehe, hält es rund 3 Stunden also ca 20k - unabhängig, wie der Rest eingestellt ist, ob OC, Fixiert oder Stock.

Ich könnte jetzt noch den Speicher untertakten, auf die offiziell unterstützten Werte (2667) Mach ich jetzt.
Dann habe ich aber wirklich alles probiert... oder fällt einem noch etwas ein?

fondness

2017-07-20, 14:58:01

Könnte es an bestimmten Teilern CPU-Takt/RAM-Takt liegen? Anders ist es schwer erklärbar, warum default nicht läuft aber übertaktet schon.

Andere Frage: Hast du AGESA 1.0.0.6a?

aufkrawall

2017-07-20, 15:00:53

omfg, ich hab doch extra bez. Stock gerade nachgefragt.

Isen

2017-07-20, 15:02:56

Jo. 1403, Aktuellste Finale Bios (https://www.asus.com/de/Motherboards/ROG-CROSSHAIR-VI-HERO/HelpDesk_Download/)

Hab den Speicher jetzt auf 2666 Rest alles Auto, weiterhin alles andere abgesteckt. Laufen tut jetzt ausschließlich nur: Board, CPU, RAM, Grafikkarte, System SSD (Samsung Evo 850) , 5 Lüfter, Pumpe (am Netzteil direkt)

Teil läuft jetzt und ist bei 200....
Damit hätte ich jetzt aber alles ausprobiert... ich wüsste jetzt nicht, was ich noch machen könnte... sobald ich Segefaults kriege oder was, sag ich natürlich bescheid.

Edit: Ich lasse gerade mein Laptop durchlaufen, sollte da nichts sein, schmeiß ich die SSD vom Lappi, mal in mein System und wiederhole den Kram.
Vlt. spackt ja meine SSD, wer weiß.

Edit: Also, mit @Stock und Speicher untertaktet auf die Offiziell unterstützten 2667 läuft jetzt schon mal deutlich länger ohne Segefaults, als wenn ich den Speicher auf Stock betreiben würde ( 3200 ) Aktuell jetzt 1500 interactionen @15:21 Uhr

Edit: 2017/07/20 15:23:25 1581: NG(-1073741819)

Edit: Mein Laptop ist soeben auch abgeschmiert :-D
Folgenden habe ich: Lenovo ThinkPad P70 20ER - wird regelmäßig von den Technikern meiner Firma, woher ich den bekomme geprüft. Dafür zahlt meine Firma jedesmal ne Menge Schotter.

Also... ja... ich sag jetzt mal nichts... ich bau jetzt alles wieder ein, mach wieder meine Stable Settings wie zuvor... Thema für mich erledigt...

Conner_Ray

2017-07-20, 15:43:23

ich hab hier ne 200€ Kiste mit einen ollen FX8350 und billigst komponenten am start, wenn mir jemand erklärt wie ich den test durchzuführen habe kann ichs auch mal probieren.

Isen

2017-07-20, 15:44:23

https://github.com/hayamdk/ryzen_segv_test/releases

ryzen_segv_test_20170712_win.zip

Launcher starten und dann folgendes eintippen > /run.sh [n] [m]---n

nachdem aber selbst mein Laptop den ich vom Arbeitgeber bekomme abgeschmiert ist, fühle ich mich gerade mächtig getrollt... bissle angepisst gerade...

Conner_Ray

2017-07-20, 15:48:01

danke, läuft

aufkrawall

2017-07-20, 15:48:48

Ich lasse es gerade doch mal laufen, will es jetzt wissen.
Testen wir auch wirklich das Gleiche?
https://abload.de/thumb/sfscs0q.png (http://abload.de/image.php?img=sfscs0q.png)

Conner_Ray

2017-07-20, 15:51:42

das bild hab ich auch, bin aber erst bei ok:200

Isen

2017-07-20, 15:52:24

Ja, gleiche.

aufkrawall

2017-07-20, 15:54:56

Ok. Ich werds wohl so bis ~33k laufen lassen, falls mir der Geduldsfaden nicht vorher reißt. Meine 8T CPU hat keine Ressourcen mehr damit fürs System. :D

Isen

2017-07-20, 16:16:57

Moment, aufkrawall, wieso hast du concurrency=8 ?

/run.sh [n] [m]---n - macht bei mir =4...

anyway... 8 - 2500000 nun laufen > 100% last - lass das jetzt noch 1x laufen, hab meine gesamten OC Settings nun wieder up und auch wieder alles eingebaut... ab 20k gab es bei mir ja nen Segefault. Mal sehen wie es jetzt ist. Meinen Firmen-Laptop nun auch nochmal.

aufkrawall

2017-07-20, 16:17:55

Weil das der Launcher als default vorschlägt. Ich hab einfach die launcher.exe gestartet und die vorgegebenen Werte übernommen.

Isen

2017-07-20, 16:31:08

Laptop und meiner 1 segefault.
Kann mich mal das Tool.
März 2017 war mein Lappi in der Wartung und Checkup, 2x macht das meine Firma im Jahr.

aufkrawall

2017-07-20, 16:31:55

Hab gleich 11k, bisher alle ok.

Conner_Ray

2017-07-20, 16:42:50

~3k bisher, keine fehler

aufkrawall

2017-07-20, 16:45:05

Ich kanns gerade nicht testen, aber concurrency ist wohl nur die Anzahl der Threads?
Bei einem R7 mit HTT sollte man dann natürlich 16 angeben.

Ätznatron

2017-07-20, 16:52:23

So, habe das gerade mal auf einem Intel 4790k versucht laufen zu lassen, ging etwa 5 Sekunden gut, dann BSOD (memory management failure).

Pirx

2017-07-20, 16:56:00

So, habe das gerade mal auf einem Intel 4790k versucht laufen zu lassen, ging etwa 5 Sekunden gut, dann BSOD (memory management failure).
alles @stock?

Isen

2017-07-20, 16:59:48

Ich kanns gerade nicht testen, aber concurrency ist wohl nur die Anzahl der Threads?
Bei einem R7 mit HTT sollte man dann natürlich 16 angeben.

Läuft noch... lappi auch. Jetzt 3000 - läuft noch.

Ätznatron

2017-07-20, 17:00:43

Natürlich nicht :biggrin:, sondern mit ansonsten immer scheinstabilem 24/7 OC.

@Stock kommt später, ich muss kurz noch was anderes erledigen.

Ganon

2017-07-20, 17:31:40

Wäre natürlich mal interessant, ob die ganzen abstürzenden, übertakteten Intel Systeme hier eine Gentoo-Installation überleben würden. :| :uponder:

aufkrawall

2017-07-20, 17:37:44

Mein Skylake-OC lief ja auch nur scheinstable und crashte bei dem Test. Damit gab es unter Linux mit GCC/LLVM mit acht Threads und generischen Compiler-Flags allerdings überhaupt keine Probleme.
Der OC 4770k meines Bruders lief zehn Minuten stabil mit dem Test, danach abgebrochen.

Bin hier auf Skylake jetzt bei 22k Loops ohne Fehler.

Conner_Ray

2017-07-20, 17:40:37

hab bei 4k aufgehört ;)
bis dahin keine fehler

Isen

2017-07-20, 17:47:14

Völlig inkonsistent der Test.
Klar, die Techniker die die arsch teuren Firmen Workstation Laptops durchchecken sind reih um alles Versager.... kann mich mal, wirklich.

Mein OC Speicher hat 12 Stunden HCI Memtest durch inkl. P95 und dann will mir das Tool was erzählen....

aufkrawall

2017-07-20, 17:54:15

Und wenn du auf dem Notebook im Bios sicherere Settings für CPU & RAM fährst?

Isen

2017-07-20, 17:56:32

Das Teil rennt Stock. Da pack ich nichts an. Firmen Teil. Das geb ich 2x im Jahr ab zum Checkup und krieg es wieder.

aufkrawall

2017-07-20, 17:58:48

Tjo, ist ja nicht unmöglich, dass da Unsinn eingestellt ist. Der Test deckt ja offenbar gerne schon den kleinsten quersitzenden Pups in der CPU-Config auf.

Isen

2017-07-20, 18:00:15

Ich glaub dem Hersteller, der das Teil verkauft inkl. den Technikern bei uns mehr, als dem Tool ... ehrlich. Wenn das Teil fehler machen würde, wie das Tool es ja meint, würde dem Hersteller der Arsch auf Grundeis gehen.
Da ist auch nix eingestellt... wie kommste darauf? Die Teile werden gekauft, kosten jedesmal 4-6k Euro das Stück und werden 2x im Jahr von unseren Technikern gewartet und durchgecheckt. Thinkpads Workstation Laptops also alle Fehlerhaft? Willst du das damit sagen?

aufkrawall

2017-07-20, 18:04:02

Ohne Test mit entschärften Settings wissen wir es nicht. Ist sicherlich ein Notebook mit Intel-CPU? Wüsste nicht, warum es dort segfaulten sollte und hier nicht, wenn das Tool allgemein unzuverlässig wäre.
Hat hier ja schon mehrere scheinstabile Configs aufgedeckt, das sollte schon zu denken geben.

Isen

2017-07-20, 18:16:05

Da gibt es nichts zu entschärfen. Die Teile werden so betrieben, wie die auch verkauft werden.

https://geizhals.de/lenovo-thinkpad-p70-20er-20er003dge-a1555322.html

Da pack ich auch nichts an. Scheiß Arbeitsgerät, je langsamer es wird, desto eher krieg ich nen neuen...

Ätznatron

2017-07-20, 18:27:27

Jetzt habe ich den Test nochmals mit OC-Settings und dem 4790k gemacht: Kein BSOD soweit.

So richtig zuverlässig ist die vom Autor gewählte Methode offenbar nicht.

Es sollte ja nicht sein, dass mit identischen Settings das Ergebnis mal so, mal so ausfällt.

aufkrawall

2017-07-20, 18:29:03

Die CPU macht ja noch andere Dinge währenddessen, die ist nie im gleichen Zustand.

Ätznatron

2017-07-20, 18:37:11

Im Hintergrund waren die üblichen Prozesse gestartet.

Nun ja, das Ergebnis bei mir ist nun mal so, wie es ist.

aufkrawall

2017-07-20, 18:38:38

Bei instabilem GPU-OC hast du ja auch teils völlig unregelmäßig auftretende Crashes.

Darkman.X

2017-07-20, 18:43:04

Ich kanns gerade nicht testen, aber concurrency ist wohl nur die Anzahl der Threads?
Bei einem R7 mit HTT sollte man dann natürlich 16 angeben.

Nee.....glaube ich zumindest. Denn auch "nur" mit 8 werden alle meine 12 Threads zu 100% ausgelastet.

aufkrawall

2017-07-20, 18:44:35

Kann sein, dass das Instanzen meint und eine Instanz mehrere Threads benutzt. Bin gleich mit 35k durch, dann teste ich das mal.

Ätznatron

2017-07-20, 18:54:58

Bei instabilem GPU-OC hast du ja auch teils völlig unregelmäßig auftretende Crashes.

Im Moment habe ich ein bisschen wenig Zeit, aber übers Wochenende werde ich mal weitertesten (dann kommt noch ein 2500k dazu und ein N3540), @Stock dann alles.

Ganon

2017-07-20, 18:56:25

Ich glaub dem Hersteller, der das Teil verkauft inkl. den Technikern bei uns mehr, als dem Tool ... ehrlich.

Naja, wenn die Kiste durch ein Userland-Tool zum Crash gebracht werden kann, dann ist daran vermutlich nicht das Tool schuld. ;) Völlig unabhängig davon was dir Techniker erzählen oder was du meinst was das Tool so für eine Qualität hat.

Ein Stück Software kann dir, ohne bösartig zu sein, die Kiste zerlegen. Da ist es keine Diskussion ob das Tool scheiße ist... da ist das Stück Hardware einfach scheiße.

So richtig zuverlässig ist die vom Autor gewählte Methode offenbar nicht.

Da keiner so richtig weiß, woran das Problem jetzt im Falle von Ryzen liegt, kann auch keiner ein deterministisches Tool bauen. Das Tool macht nichts anderes als dauernd das zu machen, was es wohlmöglich triggert. Wann es passiert kann man da nicht bestimmen.

aufkrawall

2017-07-20, 19:06:56

35k Loops erfolgreich mit dem 6700k durchlaufen:
https://abload.de/thumb/35ktuswp.png (http://abload.de/image.php?img=35ktuswp.png)

Und concurrency meint tatsächlich Instanzen. Eine Instanz lastet drei Threads voll aus. Drei Instanzen reichen also für 100% Last bei 8T, sechs bei 16T.

Edit: Es werden auch nicht durchlaufene Loops gezählt, sondern die Anzahl der Loops bestimmt die Länge eines Passes. Die Passes werden dann gezählt/überprüft.

Isen

2017-07-20, 19:16:52

Naja, wenn die Kiste durch ein Userland-Tool zum Crash gebracht werden kann, dann ist daran vermutlich nicht das Tool schuld. ;) Völlig unabhängig davon was dir Techniker erzählen oder was du meinst was das Tool so für eine Qualität hat.

Ein Stück Software kann dir, ohne bösartig zu sein, die Kiste zerlegen. Da ist es keine Diskussion ob das Tool scheiße ist... da ist das Stück Hardware einfach scheiße.
.

Ob Antivir-Software da zwischenfunken kann etc...
Daher sagte ich ja: INKONSISTENT - man weiß nämlich nicht, ob es auch tatsächlich die Hardware ist....
Ich habe beim Lappi nun den Antivir deaktiviert und bin jetzt bei 12k interactionen. War vorher nicht im Ansatz Möglich.

Das gleiche habe ich jetzt bei meinem Ryzen gemacht und bisher rennt es... mal sehen.

aufkrawall

2017-07-20, 19:22:31

Wenn irgendetwas anderes als der Test selbst nicht mehr richtig läuft oder gar das ganze System crasht, wird es mit hoher Wahrscheinlichkeit an der Hardware liegen. AVs sind natürlich so ne Sache, die pfuschen u.U. unorthodox im Speicher rum.

Isen

2017-07-20, 19:25:54

System ist hierbei nicht abgestürzt mit dem Tool. Immer nur das Tool selbst, wenns nen Segefault gab, lief aber natürlich trotzdem weiter

aufkrawall

2017-07-20, 19:36:29

Ich würd drauf achten, dass der concurrency-Wert so gesetzt ist, dass man 100% erreicht (also 6 für R7 16T). Der Loop-Wert ist womöglich auch wichtig, würd da jetzt pauschal auch erstmal nichts anderes als die 2500000 empfehlen.

Ich hab hier keine Inkonsistenz mit dem Test. OC crasht, stock nicht. Ich hab keine AVs am laufen oder sonst etwas, was irgendwie Prozesse manipulieren könnte.

Isen

2017-07-20, 20:13:08

Malewarebytes wohl schon. Hab den aus.. beim Ryzen System. Bin jetzt bei 12k
Die Daten/Ergebnisse hab ich aber schon alles an AMD gemailt. Mal sehen :-)
Asus habe ich nun auch ne Mail geschickt, wieso bei DEFAULT das Board die CPU bzw. den Multiplier eigenmächtig von x30 auf x32 erhöht, selbst wenn x30 fixiert wird.

Edit: Naja 6 = 100% ist auch net richtig... bei 5 habe ich schon 95% ( 4 = 75% )... 6 ist da dann schon zuviel.. naja meiner rennt Aktuell noch mit 6 und 2500000 ... mit OC Settings btw. Stock kann ich nicht tun, da das Board wie gesagt, eigenmächtig die CPU übertaktet, obwohl Default bzw. Fixiert. Ganz klar nen Bios Fehler. Neu aufgespielt hab ich es auch schon, falls das wer fragen sollte.

Ganon

2017-07-20, 21:44:49

System ist hierbei nicht abgestürzt mit dem Tool. Immer nur das Tool selbst, wenns nen Segefault gab, lief aber natürlich trotzdem weiter

Ah OK, das war jetzt aus:

Edit: Mein Laptop ist soeben auch abgeschmiert :-D

nicht ersichtlich. ;) Der Test ist wohl ein ziemlich guter Stress-Test wie sich herausstellt, der auch teilweise kleinste Overclocking-Maßnahmen bis zum Bluescreen unter Windows führt, laut den Leuten hier.

Muss ja nicht heißen, dass dein Arbeits-Notebook ansonsten nicht OK ist. Er überlebt halt nur genau den Stresstest nicht. Mein Notebook würde, laut damaligen Tests, unter Umständen einen puren AVX(2) Dauerstresstest auch nicht überleben, aufgrund von Hitze. Das kommt aber in der Realität auch nicht vor und dementsprechend nicht sinnvoll "zu beheben". Eine Woche Dauerrendering in Blender/Cycles hat er zumindest überlebt.

Isen

2017-07-20, 21:51:38

Ich hab meine OC Settings mitm Ryzen nun auf 20k laufen. Bevor ich in die Haia gehe sollten vielleicht 30k drin sein, mal sehen. Geändert habe ich nur folgendes:

PLL Voltage auf 1,90v anstelle 1,85v (Default sind 1,80v)
SoC Fixiert auf 1,100v ( Default unter 0,850-0,990v )

Das wars...
ALLES auf Stock läuft es jedenfalls NICHT, weil mein Board, trotz fixierung des Multiplier, die CPU um 200mhz übertaktet (Multiplier eigenmächtig auf x32 setzt)

Erhöhung der Vcore, weil das Board übertaktet, half nicht.

Sehr sehr komisch das alles....

Laptop gleich bei knapp 50k. Antivir dazwischen gefunkt... deaktivierung also geholfen.

@Ganon,

mea culpa :-)

Edit: Laptop bei 100k aus gemacht. Läuft. Antivir die Ursache gewesen.
Ryzen läuft auch, kurz vorm pennen gehen bei 39k aus gemacht...
Alles auf Stock läuft es nicht... sehr kurios...

Bleibt eigentlich nur noch folgendes: Board/Bios respektive Bestandteile vom AGESA 1006 sind die Ursache oder die festgelegten Settings, sei es Spannung oder sonstwas, sind zu niedrig angesetzt.
Wie oben geschrieben, habe ich nichts anderes gemacht, als die SoC auf 1,100v fixiert und die PLL Voltage auf 1,90v von Default 1,80v. - bissle Schmunzeln muss ich schon, Stock nicht stabil, OC stabil :D

aufkrawall

2017-07-21, 13:44:34

Du bist du also recht sicher, dass du es durch die Spannungsanpassungen von PLL und SoC stabil bekommen hast, auch mit Stock-Taktraten von CPU und RAM?

Isen

2017-07-21, 13:54:13

Schrieb ich doch:

ALLES auf Stock läuft es jedenfalls NICHT, weil mein Board, trotz fixierung des Multiplier, die CPU um 200mhz übertaktet (Multiplier eigenmächtig auf x32 setzt)

Erhöhung der Vcore, weil das Board übertaktet, half nicht.
CPU OC und Speicher OC mit den angepassten Voltages SoC/PLL läuft es aber...

CPU Stock (naja, das Brett macht halt 3,2Ghz draus) + Vcore + SoC + PLL das habe ich noch nicht getestet.

Daedalus

2017-07-21, 17:39:55

Ich habe das Tool in einem Manjaro Linux getestet. @Stock habe ich nach ca. 10k erstmal abgebrochen, vorgestern unter Windows 10 bekam ich schon nach 2-300 ngs. Fünf mal Mesa kompilieren ging auch ohne Probleme. Der Witz ist, jetzt läuft es unter Windows bisher ohne Probleme @Stock bei aktuell 2k...

Vielleicht lasse ich das ganze mal heute Nacht laufen.

Edit:
Ich glaube den/die Übeltäter gefunden. Scheinbar waren meine tRC und TRFC Timings zu scharf eingestellt. Kann sein, dass ich diese bei vorherigen Tests vergessen hatte zurück zu setzten. Dödöm...

Isen

2017-07-21, 21:20:20

Edit:
Ich glaube den/die Übeltäter gefunden. Scheinbar waren meine tRC und TRFC Timings zu scharf eingestellt. Kann sein, dass ich diese bei vorherigen Tests vergessen hatte zurück zu setzten. Dödöm...

Interessanter Ansatz....
Hab erneut alles auf Default, d.h. mein Speicher läuft dann sogar nur auf 2133mhz - die Timings allerdings habe ich nun mal von Hand angepasst, also jene die Rechnerisch zu ermitteln sind und die Sub-Timings nochmals entschärft - das läuft jetzt bis 5k ... vorher war Default ja, innerhalb von 2min Segefault.

Bestätigt dann, dass die XMP 2.0 Problematik noch nicht überstanden ist erklärt dann auch, wieso mein OC Setting mit den Handoptimierten Primär und Sub-Timings beim Speicher läuft, während Stock Default es nicht tut, da da bereits dort schon die Timings nicht wirklich lauffähig sind...

Auch die im XMP Profil von meinem Speicher sind nicht Lauffähig, die muss ich auch Manuell anpassen, damit das läuft.

Ich lass mal weiter laufen...

Daedalus

2017-07-21, 21:56:44

Tatsächlich hatte ich die von Hand eingestellt, aber vergessen wieder auto zu setzten für den Stock-Test. Hatte tRC=48 und TRFC=312, tRC=56 scheint stabil zu sein. XMP-Timings waren 75 bzw. 560.

Isen

2017-07-21, 22:08:03

Jo. die XMP 75 und 560 sind bei mir nicht lauffähig. Hab daraus 77 und 570 gemacht. Läuft immer noch.

aufkrawall

2017-07-22, 15:40:19

Und wenn du Ryzen Master nimmst, um Stock-Werte erreichen zu können?

Isen

2017-07-22, 17:07:40

Ja, damit werden die 3,0Ghz forciert.
Mein Board bzw. Bios hat MÄCHTIG rumgezickt deswegen.... da gab es jetzt 18 komplette neustarts, bis das System dann endlich gestartet ist.
Aber bin nun wieder in Windows, und es ist nun tatsächlich alles auf Default.
Das Default vom Bios heraus, ist nachdem ich nun die Default-Werte via Ryzen Master forciert habe und betrachte, gar nicht wirklich Defaults gewesen... jetzt habe ich tatsächlich mal Default-Werte in allen belangen.
Scheiß Bios also noch diverse Macken.

Habe auch gestern ein Video gesehen, da hat man den R7 1700 gebencht mit den neuen HEDT Intels, bei dem war sein 1700 auch auf 3,2Ghz, trotz out of Stock test. Sehr sehr strange.
Ich weiß aber noch zu 100% - das mit dem auslieferungsbios bzw. AGESA 1004 beim ersten start ins Windoof mit 3,0Ghz getaktet hat. Da ich recht früh angefangen habe zu übertakten fiel mir das bei jedem neuen Bios bzw. nun AGESA 1006 und 1403 Bios von Asus nicht auf..

Tool habe ich jetzt angeschmissen - bei all meinen Tests kam ich NIE höher als 3000 Interactionen wo ich die aus dem Bios heraus gesetzten DEFAULTS geladen habe, jetzt schaue ich mal, wie weit ich komme... ich denke, ich lass das mal bis 40k laufen, wie auch mein OC der bis 39K fehlerfrei lief.

Daedalus

2017-07-22, 17:13:56

War nicht 3,2 GHz All-Core-Boost @Stock?

Isen

2017-07-22, 17:23:08

Der R7 1700 hat Allcore 3,2Ghz / boost zwei ein Kern 3,7Ghz - gut, alle Tools können den Internen Vorgang nicht auslesen (Shadow-State) gut möglich, dass die Tools das "Mitteln" und als 3,2Ghz Allcore interpretieren - Windows spielt da auch mit rein, was im Gegensatz zu Linux, zu dumm ist, dies korrekt zu interpretieren.
Der R7 1700X hat Allcore 3,4Ghz
Der R5 1600 hat Allcore 3,2Ghz

Haha.. hab ich hier nen R5 1600 mit 2 zusätzlichen kernen :P ( Issn Witz! )

btw: Mit Ryzen Master bei 600 Segefault.
Bin nun ins Bios hab radikal das Bios neu geflasht und direkt nach dem Flash gebootet und nun das Tool angeschmissen. Das sieht nun wie folgt aus:

Edit: So neues Bild, mit mehr Infos:

https://abload.de/img/tool23zsj6.png (http://abload.de/image.php?img=tool23zsj6.png)

iuno

2017-07-22, 17:30:25

Es trat mit den pkgbuilds für linux-mainline und llvm-svn bei default flags und 16 Threads auf (aber nicht immer). Weniger Threads nicht getestet.
Kernel habe ich schon oft gebaut, da ist noch nie was passiert.
bei llvm-svn hat es jetzt tatsaechlich mal in einem Durchlauf gekracht :usad:

Das Tool hatte ich bei 30k ohne Fehler abgebrochen.

aufkrawall

2017-07-22, 17:56:40

Gut, dass du genau mein Problem bestätigen kannst. :up:
War das mit @ stock, Kompilieren brach mit segfault ab?

iuno

2017-07-22, 18:03:18

Ne, 3,6 all cores beim 1700, Spannungen alle normal. Stock kann spaeter ich nochmal probieren, habe allerdings ein paar Anlaeufe gebraucht.
ja, segfault.

Isen

2017-07-22, 18:07:51

3,6Ghz, sicher?

https://www.amd.com/de/products/cpu/amd-ryzen-7-1700

Anzahl der CPU-Kerne 8 Anzahl von Threads 16 Basistaktrate 3GHz Max Turbo Core Speed 3.7GHz Gesamter L1-Cache 768KB Gesamter L2-Cache 4MB Gesamter L3-Cache 16MB Freigegeben Ja Package AM4 PCI Express Version PCIe 3.0 Thermal Solution Wraith Spire (LED) Default TDP / TDP 65W Max Temps 95°C

Edit:
People seem to misunderstand XFR a great deal with Ryzen and retailers don't help by marketing the 1700 as a 3.7ghz CPU which it's not, it's a 3.0ghtz CPU. Only one core can hit 3.7 (3.75 with XFR)

Turbocore clocks on the 1700 will up-clock ALL cores at once to 3.2ghtz, however XFR will ONLY work on ONE core and then ONLY when the other 7 cores are idle

Hinzu kommen die Shadow-States, was unter Windows nicht ausgelesen werden kann, Linux hingegen kann das.

iuno

2017-07-22, 18:12:22

Ja, ich bin auf 3,6 (all cores, Standard ist da 3,2) weil er sonst mehr Spannung braucht. Mit XFR und Boost gehen die ja schon hoch ohne Ende. Stimmt eigentlich schon, dass ich eher stock testen sollte, wenn es offenbar nahe bei der Grenze liegt :ulol:
edit zum edit: hab bei mir kein XFR und Turbo an.
Speicher muesste ich dann auch runter nehmen? Formal sind 2933 MHz ja auch OC...

Isen

2017-07-22, 18:21:15

So, hier.
Bitteschön:
Schick ich gleich AMD hinterher.

https://abload.de/thumb/segefault2lmuxz.png (http://abload.de/image.php?img=segefault2lmuxz.png) https://abload.de/thumb/segefault22lku74.png (http://abload.de/image.php?img=segefault22lku74.png)

[...]
2017/07/22 18:19:33 9448: OK
2017/07/22 18:19:34 9452: OK
2017/07/22 18:19:34 9314: NG(255)
2017/07/22 18:19:34 9450: OK
2017/07/22 18:19:35 9458: OK
2017/07/22 18:19:35 9455: OK

Gleich nochmal ( neu gestartet )

https://abload.de/thumb/segfault2233kxmr.jpg (http://abload.de/image.php?img=segfault2233kxmr.jpg)

2017/07/22 18:39:56 1988: OK
2017/07/22 18:39:56 1992: OK
2017/07/22 18:39:56 1911: NG(255)
2017/07/22 18:39:57 1922: NG(255)
2017/07/22 18:39:57 1993: OK
2017/07/22 18:39:58 1999: OK

Hab jetzt alles mögliche rauf und runter getestet...
Was nun?

Isen

2017-07-22, 18:23:17

edit zum edit: hab bei mir kein XFR und Turbo an.
Speicher muesste ich dann auch runter nehmen? Formal sind 2933 MHz ja auch OC...

Japp. 2133 ist Stock.
Bei nem Bios Flash wird ja alles radikal zurückgesetzt, hab nichts gemacht nach dem Flash.
Werte wie im Screen sind Default. Wenn du aber unter Linux testest? Dann vergleich nicht die Takraten, Linux kann die Shadow-States auslesen, im Gegensatz zu Windows und die ganzen Tools.

Edit: Sorry Doppelpost.

Edit:

Neues Beta Bios für das C6H

http://www.mediafire.com/file/g108edb002b08h2/CROSSHAIR-VI-HERO-ASUS-9920.zip

New beta UEFI 9920 for the C6H

* Improved DRAM cold boot, results in slightly longer POST time
* Fix for CPU Ratio stuck at 22x on some CPUs when using Vcore override/offset
* SenseMi Skew is now Disabled by default. If you want to return to previous behavior set SenseMi Skew = Enabled and Offset = 272.
* Added DRAM profiles for Samsung B-based DIMMs with tuned subtimings, including The Stilt's settings

Quelle: https://rog.asus.com/forum/showthread.php?91766-Crosshair-VI-Hero-UEFI-build-9920-amp-1403&p=663019&viewfull=1#post663019

Ich teste also ERNEUT ...

Nett ist der Support ja schon....

http://abload.de/img/900x900px-ll-d4eb83dtosxi.jpeg

gravitationsfeld

2017-07-22, 21:29:30

Ich hab die Probleme uebrigens auch mit dem Microsoft-Compiler auf einer Ryzen-Box. Der Test schlaegt auch sofort an.

Vielleicht ist aber der RAM kaputt. Ich ersetz ihn Montag mal.

StefanV

2017-07-22, 23:09:16

Vielleicht ist aber der RAM kaputt. Ich ersetz ihn Montag mal.
Das wäre auch meine Vermutung...

Wenn du/ihr Geld und ein ASUS, ggF Gigabyte Board habt und euch die Performance nicht soo wichtig ist, besorgt euch doch mal 'nen Paar unbuffered ECC Riegel und testet es damit...

Isen

2017-07-22, 23:14:27

Hab meinen Speicher vom anderen Rechner rein gehauen. Selbe :-(
Hau jetzt mal Memtest aufm Stick und Boote. Lass Memtest mal drüber.

Gorkon

2017-07-22, 23:57:44

Was ist, wenn ihr den Speicher nach der "alten Faustregel" einstellt? Wenn das Problem denn überhaupt am RAM(Takt) liegt...

tCL + tRCD + tRP == tRAS
tRAS + tRP == tRC

http://www.masterslair.com/memory-ram-timings-latency-cas-ras-tcl-trcd-trp-tras

Isen

2017-07-23, 00:05:46

Hatte ich auch schon durch. Default berücksichtigt genau diese Regel ^^

Oder es ist schlicht ein Compiler Bug....

Ich pack das Teil jetzt mal auf meine HDD statt auf der System-SSD... wenn nix draus wird, während ich penn lass ich dann memtest via Bootstick drüber latschen, wobei der Speicher 100 Loops mit Memtest64 ohne Fehler Überstanden hat.

Gorkon

2017-07-23, 00:09:40

Sicher @Default?

15 + 15 + 15 == 45 und nicht 36
45 + 15 == 60 und nicht 51

Ich weiß schon, dass der Kram für DDR4 wohl nicht mehr ganz gilt, weil tRAS auch nur ein Mindest(!)wert ist (Der DRAM-Controller kann ja wahrscheinlich selber das Fenster länger offen halten), aber wirklich "Faustregel" war das nicht ;)

Btw. Default...theoretisch sollte ja alles bis DDR4-2666 fehlerfrei laufen "müssen", bis dahin isses ja kein OC.

mfg

Isen

2017-07-23, 00:21:03

Ich hab es berücksichtigt, weiter hinten schrieb ich ja, " rechnerisch " etc.. und jene wo das egal ist, entsprechend entschärft, wo jeder Gammelspeicher mit pups-ICs laufen würde.
Am Speicher liegt es definitiv nicht.

Ich hab das Tool mittlerweile über 24h laufen gehabt.. ich hab alles durchgetestet... vieles davon schickte ich schon AMD. Da warte ich noch auf Rückmeldung. Davon ist vieles hier nur rein Schriftlich hier berichtet worden. Häng dich also nicht an die Heutigen Screenshots fest.
Asus hab ich auch angeschrieben, ob da die Möglichkeit besteht, dass da seitens des Boards/Bios was nicht rund läuft etc...

Edit: Hier, mit denen hab ich als aller erstes angefangen gehabt, dass waren meine Stable Settings( 12h HCI Memtest +P95 ), womit ich ohne Probleme meinen Kram machen konnte, ehe ich hier reingeschaut hab
https://abload.de/img/done43xtp.png (http://abload.de/image.php?img=done43xtp.png)

UND JETZT, hab ich das Tool eben auf die HDD geschmissen statt System-SSD und nutze jetzt folgende Timings ( Das sind die Presets vom neuem Bios, die die ^^ Regel nicht berücksichtigt ) der unterschied zwischen meinen und die des Presets, liegt schon mal darin, dass der L3/L2 weniger Latenz hat. Vergleiche beide halt miteinander, was besser läuft und nutze es eben jetzt auch für das Tool. Bin jetzt bei 5600 Interactionen, bisher kein Segfault.
https://abload.de/img/blub9brwd.jpg (http://abload.de/image.php?img=blub9brwd.jpg)

Gorkon

2017-07-23, 00:34:57

Schon ok...ist halt wirklich ne seltsame Sache mit den Segfaults. Treten ja anscheinend auf wie sie lustig sind. Bzw. anscheinend ja nicht für die Dragonfly-Linuxer nach dem Patch...

Kein Strahl was sich da nicht per µCode fixen lassen soll :confused:

Isen

2017-07-23, 00:40:33

Die sind sich dort eh noch nicht einig...

So how is that all ryzen fault, not eg bad flags or gcc bug ?
I dont have segfaults showing in dmesg- but i had 3 x internal compiler errors - after another emerge package was successfully compiled somehow.

ich teste und fummel solange daran weiter, bis ich den Schuldigen gefunden habe, kein Problem damit.
Aus lauter Freude mach ich das jedenfalls nicht, will das schließlich auch wissen, was das ist, ehe irgendwelche "Honks" falsche Schlüsse ziehen, die nicht mal einen Ryzen haben :D

P.S

Edit: 00:50 Uhr 8K Interactionen ....
Edit: 00:55 Uhr 9K Interactionen ....
Edit: 01:01 Uhr 10K Interactionen ....
Edit: 01:06 Uhr 11K Interactionen ....
Edit: 01:11 Uhr 12K Interactionen ....
Edit: 01:17 Uhr 13K Interactionen ....
Edit: 01:22 Uhr 14K Interactionen ....
Edit: 01:27 Uhr 15K Interactionen ....
Edit: 01:33 Uhr 16K Interactionen ....
Edit: 01:38 Uhr 17K Interactionen ....
Edit: 01:43 Uhr 18K Interactionen ....
Edit: 01:49 Uhr 19K Interactionen ....
Edit: 01:54 Uhr 20K Interactionen ....
Edit: 01:59 Uhr 21K Interactionen ....
Edit: 02:04 Uhr 22K Interactionen .... ein Film hab ich noch :D
Edit: 02:10 Uhr 23K Interactionen ....
Edit: 02:16 Uhr 24K Interactionen ....
Edit: 02:22 Uhr 25K Interactionen ....
Edit: 02:28 Uhr 26K Interactionen ....
Edit: 02:34 Uhr 27K Interactionen ....
Edit: 02:40 Uhr 28K Interactionen (https://abload.de/img/28kd8s51.jpg).... bä.. wird ganz langsam immer langsamer - kein bock mehr, guck Film Ende. Ich lass die Nacht durchlaufen. Achja: Das Tool wie gesagt statt von der System-SSD auf die HDD gehauen und Ryzen Balance Plan (Energieeinstellung) auf Höchstleistung geändert und im Bios habe ich den Performance Bias vergessen auf AUTO zu stellen, der steht also jetzt während das Tool läuft auf AIDA/Geekbench. Das wars.
Edit: 02:46 Uhr 29K Interactionen ....
Edit: 02:52 Uhr 30K Interactionen (https://abload.de/img/30k7yal3.jpg) ....

Gutschi Gutschi - Segfault.. oh mann (https://abload.de/img/segfaults1o7s.jpg)

2017/07/23 03:00:07 31347: OK
2017/07/23 03:00:07 31280: NG(255)
2017/07/23 03:00:08 31350: OK
2017/07/23 03:00:08 31276: NG(255)
2017/07/23 03:00:09 31351: OK

gn8 denn...
memtest ist nun aufm Stick, ich lass das jetzt die Nacht durchlaufen.

Gorkon

2017-07-23, 11:38:39

Es wird immer besser :freak:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399#c87
https://github.com/hayamdk/ryzen_segv_test/pull/3

https://github.com/suaefar/ryzen-test (Save-Ryzen soll angeblich NICHT crashen, anderer Ansatz...es wird GCC kompiliert, VIEL RAM benötigt da eine RAM-Disk angelegt wird)

- Der Segfault-Test crasht unterschiedlich schnell je nach GCC-Version mit der er kompiliert wurde.
- Bei jedem betroffenen helfen anscheinend vollkommen Unterschiedliche Maßnahmen (Spannung hoch / runter, Takt hoch / runter, OP-Cache aus, SMT aus, LLC, anderer Kernel, ASLR aus, Feenstaub, Voodoopuppen ;) etc. etc.) (https://community.amd.com/message/2812825#comment-2812825)
- Der Segfault-Test reißt ja sogar nicht-AMD-System in den "Tod". Die müssten dann ja auch irgendwie "defekt" sein...

Jede CPU-(Arch) hat ihre Macken, Ryzen offensichtlich ja auch und ich will das jetzt echt nicht runterspielen...aber die ganze Problematik ist soooooooo fischig in diesem Fall, dass ich persönlich erstmal die Füße komplett still halten würde. Mal schauen ob dieser Fehler in B2 (Epyc) auch besteht. RMAen kann man das Teil immer noch, wenn sich absolut nix tut.

Im Endeffekt tappen wahrscheinlich alle außer AMD im Dunkeln.

Was man vielleicht wirklich noch probieren könnte:
- DragonFly BSD installieren und schauen, ob der Fehler dort nicht auftritt (soll er ja anscheinend nicht)
- Irgendwo ne Bristol Ridge APU für AM4 herbekommen und schauen ob der Fehler dort auch auftritt (Ausschluss des Fehlers in der Plattform AM4 an sich)

mfg

Isen

2017-07-23, 18:10:33

Bristol Ridge Laptop kann ich auftreiben :-)

Gorkon

2017-07-23, 19:30:54

BR-Schleppi wäre ja schon wieder was anderes. Ich meinte wirklich ne AM4 BR-APU wie von hier:

https://www.csl-computer.com/shop/product_info.php?products_id=13308&cPath=61_68&XTCsid=i0jmit1bvlv879vmk0nb6rk902

Und dann halt mal bei nem betroffenen System (CPU), die CPU austauschen und gucken was BR dann veranstaltet. AGESA ist ja nicht nur Ryzen-Exklusiv :D
Alles aber natürlich nur unter der Voraussetzung, dass die Segfault-Testprogramme nicht selber irgendwelchen Schabernack machen. Richtiges Kompilieren als Vergleich ist ja nun doch irgendwie anders.
Und deswegen auch mein "Füße stillhalten". Das so gegenzutesten bringt wahrscheinlich am Ende überhaupt nix, also ob es an den Mainboards liegen würde, aber man hat ja schon Pferde kotzen sehen ;) Trotzdem höchst spekulativ und wahrscheinlich Schwachsinn...

Daher würde ichs eher mal mit DragonFly ausprobieren. Einfacher / Billiger und im Zweifelsfall helfen ja wirklich die 2 Patches für Ryzen dort gegen das Problem.
Ich versuch mal die Tage den ganzen Kram bei der Holden nachzustellen...aber nur, wenn sie Dienst hat X-D Bei meinem Glück mit Hardware crasht die Kiste sicherlich nach 10 Sek.

aufkrawall

2017-07-23, 19:46:22

Nur noch mal zur Klarstellung: Ich hab mit dem 6700k noch genau den selben Speicher wie mit dem 1700, und mit dem Intel tritt das Problem definitiv nicht auf, trotz voll ausgefahrenen RAM-Takts.
Kann llvm kompilieren wie ich lustig bin (ist nur leider auf Dauer etwas öde...), bei iuno trat es offenbar dabei wie bei mir mit dem 1700 relativ schnell auf. Zufälle gibts. ;)

StefanV

2017-07-23, 19:55:01

Nur noch mal zur Klarstellung: Ich hab mit dem 6700k noch genau den selben Speicher wie mit dem 1700, und mit dem Intel tritt das Problem definitiv nicht auf, trotz voll ausgefahrenen RAM-Takts.
Irrelevant, da anderer SPeichercontroller, der Speicher anders angesteuert wird.

Rowhammer ist dir bekannt?

Und, wie im anderen Thread geschrieben, läuft mein Elixier Riegel nicht auf den LGA2011 Systemen. Und auch mit den Mushkin Values habe ich Probleme. Im Kaveri: 0 Problemo.

Ätznatron

2017-07-23, 20:01:39

Und bei meinem Intel musste ich den RAM-Takt senken auf XMP-Vorgaben, dass er auch über einen längeren Zeitraum keinen Fehler auswarf.

aufkrawall

2017-07-23, 20:07:52

Irrelevant, da anderer SPeichercontroller, der Speicher anders angesteuert wird.

Rowhammer ist dir bekannt?

Und, wie im anderen Thread geschrieben, läuft mein Elixier Riegel nicht auf den LGA2011 Systemen. Und auch mit den Mushkin Values habe ich Probleme. Im Kaveri: 0 Problemo.
Es geht darum, dass der Speicher nicht defekt ist.

StefanV

2017-07-23, 20:39:18

Das nutzt jetzt genau wieviel, wenn der RAM inkompatibel ist und deswegen nicht läuft?!

aufkrawall

2017-07-23, 20:52:55

Steht auf der AMD-Liste als kompatibel, ist Samsung Single Rank...

StefanV

2017-07-24, 03:43:03

Insbesondere da die Arbeit, die Isen gemacht hat, durchaus auf Probleme mit den RAM Timinigs schließen lässt.

Ob das ganze jetzt mit einer komplett anderen Plattform funktioniert, ist dabei völlig irrelevant...

Aber hier sind wir wieder beim üblichen AMD Problem: Wenn was bei AMD nicht sofort und auf der stelle funktioniert, wird gleich rumgemeckert und geflamt.
Bei anderen Herstellern wird mehr Zeit (und auch Geld) investiert, um irgendwelche Probleme zu finden und auszumerzen.

Letztendlich bleibt fast nichts anderes übrig als dass jemand, der einen Ryzen mit ASUS Board (AFAIR auch GIgabyte, Asrock weiß ich nicht) besitzt und sich mal z.B. davon 2 Riegel kauft:
https://geizhals.de/?cat=ramddr3&xf=5828_DDR4~5830_unbuffered+ECC+(UDIMM)~5831_DIMM
Und mal schaut, ob ECC etwas an der Sache ändern kann/wird...

Steht auf der AMD-Liste als kompatibel, ist Samsung Single Rank...
Und das Board als Ursache blenden wir aus?

gravitationsfeld

2017-07-24, 04:47:18

Es ist immer irgend was anderes, klar.

Isen

2017-07-24, 05:27:51

Insbesondere da die Arbeit, die Isen gemacht hat, durchaus auf Probleme mit den RAM Timinigs schließen lässt.

Auch die Stock/Defaults haben das Problem. Wenn dann glaube ich eher, dass das mit XMP 2.0 zutun hat und der IMC da unter langer Last da Probleme macht, als die Timings an sich. Ob ich die jetzt selbst errechneten verwende (damit läuft es länger) oder die aus dem XMP Profil ( die halten knapp 10min )
Wobei sämtliche Tools die den Speicher UND CPU stressen, mehr als das Tool, da keine Fehler finden oder anschlagen....

...mir den ollen Speicher da kaufen, tue ich jetzt nicht :D - die Kiste rennt für all meine Belange ohne Probleme. Warte ohnehin erstmal auf diverse Rückmeldungen ab, ehe ich weiter irgendwas versuche.

gravitationsfeld

2017-07-24, 05:36:39

Der readme nach testet das Program primaer selbstmodifizierenden Code. Aus anderen Berichten geht hervor, dass es der Microcode-Loop-Cache ist, was dazu passen wuerde. Selbstmodifizierender Code ist sehr unueblich, vor allem wenn Code staendig ueberschrieben wird. Das wuerde erklaeren, warum es nur in bestimmten Programmen auftritt.

Ich bezweifle, dass es irgendwas direkt mit dem Speicher zu tun hat. Viele Variablen koennen aber beinflussen koennen wenn die fehlerhafte Bedigung im Prozessor erzeugt wird.

Isen

2017-07-24, 05:43:15

witzig... Tool gerade mal laufen gehabt, wollt was testen... hat einfach aufgehört - im Task Manager öffnet sich immer kurz ein neuer Prozess, der wird von Windows aber immer wieder sofort gekillt :D

Michalito

2017-07-24, 08:12:04

ECC Ram könnte ich verleihen.-* Wenn Isen möchte schicke ich ihm welchen..Bitte P.M. bei Intresse..

*Oder auch verkaufen..

M3NSCH

2017-07-24, 10:47:05

kann mir mal jemand erklären was ich hier nun tu? :redface:

habe jetzt einfach mal ./run.sh 8 250000 eingegeben .... cpu auslastung 100%
was passiert da jetzt?

sys:
https://abload.de/img/capturehkqwm.png

all@ stock , arch

StefanV

2017-07-24, 18:24:28

Es ist immer irgend was anderes, klar.
nein, aber das ganze erinnert an ECS K7S5A mit ab Werk kaputtem (NoName) Speicher, Codegen Netzteil und dem alten Pentium 1 Kühler bzw mit Glück einem S370 Kühler, um dann Marodierend durch die Foren zu ziehen...

Bei der anderen Seite wird sachlicher nach der Ursache gesucht, bei AMD wird erst einmal der Hersteller grundsätzlich verurteilt. Das siehst du auch in diesem Thread, dass einige Leute zwar sachlich agieren und versuchen dem ganzen auf die Spur zu kommen, während andere einfach nur AMD bashen, obwohl noch nicht wirklich klar ist, was denn nun die Ursache ist.

Auch du weißt es nicht, du vermutest es nur.
Und genau das ist es, was ich meinte...

Und damit sind wir dann wieder bei dieser Aussage:
Aber hier sind wir wieder beim üblichen AMD Problem: Wenn was bei AMD nicht sofort und auf der stelle funktioniert, wird gleich rumgemeckert und geflamt.
Bei anderen Herstellern wird mehr Zeit (und auch Geld) investiert, um irgendwelche Probleme zu finden und auszumerzen.

Das ist es, was mich stört...
AMD gibt man meistens gar keine Chance, bei Intel wechselt man ggF sogar noch das Board und versucht ein anderes, wenn man nicht so ganz zufrieden ist...

gravitationsfeld

2017-07-24, 18:49:31

Es ist nicht der Speicher.

Isen

2017-07-24, 21:35:03

ECC Ram könnte ich verleihen.-* Wenn Isen möchte schicke ich ihm welchen..Bitte P.M. bei Intresse..

*Oder auch verkaufen..

Danke fürs Angebot.
Ich könnte selbst von der Arbeit ein paar auftreiben. Dauert aber nur etwas.
Hoffe das ich in nächster Zeit etwaige Rückmeldungen kriege.

Kann mir mal wer nen Link geben oder kurz erklären, was der opcache tut ?
Edit: Lese gerade, gibt wohl bald nen Microcode update.

Hier was neues:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399#c89

Ganon

2017-07-24, 23:24:59

Hier was neues:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399#c89

Da steht auch, dass auch jemand mit ECC RAM die Probleme hat und beim Crash keinerlei Bitfehler vom RAM gemeldet werden.

Kann mir mal wer nen Link geben oder kurz erklären, was der opcache tut ?

Das hier vielleicht:
http://www.anandtech.com/show/10578/amd-zen-microarchitecture-dual-schedulers-micro-op-cache-memory-hierarchy-revealed

Im Endeffekt aber ein Cache für die Übersetzung x86 Befehl -> interner(e) CPU Befehl(e).

Isen

2017-07-25, 00:45:03

Ah. Danke dir.

Das probiere ich jetzt mal unter FreeBSD aus:

(In reply to Nils Beyer from comment #91)
I'm pretty sure that ryzen_segv_test is actually broken. The first iteration of the loop in the t2 threadx() is unlocked and there is no guarantee that it will have initialized things before thread1() tries to use them.

Try this patch:

--- ryzen_segv_test.c.orig 2017-07-24 14:26:23.851846000 -0700
+++ ryzen_segv_test.c 2017-07-24 15:02:33.998102000 -0700
@@ -291,29 +291,32 @@
atomic_store(&flg, 0);
}

+void threadx_core()
+{
+ uint8_t offset;
+ uint32_t randval;
+
+ offset = random() % 256;
+ randval = random();
+ memset(func_set, 0, sizeof(func_set_t));
+ memcpy(&func_set->func[offset], func_base, FUNC_BYTES);
+ func_set->offset = offset;
+ func_set->ret = randval;
+}
+
void threadx(void *p)
{
uint8_t offset;
uint32_t randval;
int init = 0;
- if(p != NULL) {
- init = 1;
- }

//usleep(1000);

while(atomic_load(&flg)) {
offset = random() % 256;
randval = random();
- if(!init) {
- lock_enter();
- } else {
- if(func_set == MAP_FAILED) {
- fprintf(stderr, "mmap returns MAP_FAILED!\n");
- return;
- }
- init = 0;
- }
+ lock_enter();
+ // threadx_core();
memset(func_set, 0, sizeof(func_set_t));
memcpy(&func_set->func[offset], func_base, FUNC_BYTES);
func_set->offset = offset;
@@ -330,8 +333,7 @@
{
int64_t loops;
pthread_t t1, t2, t3;
-#ifdef _MSC_VER
-#else
+#if !defined(_MSC_VER) && !defined(__FreeBSD__)
cpu_set_t cpuset;
int cpu;
#endif
@@ -349,19 +351,23 @@
n_cpus = sysconf(_SC_NPROCESSORS_ONLN);
func_set = mmap (NULL, sizeof(func_set_t), PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
#endif
+ if(func_set == MAP_FAILED) {
+ fprintf(stderr, "mmap returns MAP_FAILED!\n");
+ exit (1);
+ }

atomic_store(&flg, 1);
atomic_store(&locked, 1);

srandom(time(NULL) + pid);
// You should confirm assembly of generated code, just in case the compiler reorders mfence instruction
+ threadx_core();
mfence(); // Assure that flags are stored properly
pthread_create(&t1, NULL, (void*)thread1, &loops);
- pthread_create(&t2, NULL, (void*)threadx, (void*)1);
+ pthread_create(&t2, NULL, (void*)threadx, NULL);
pthread_create(&t3, NULL, (void*)threadx, NULL);

-#ifdef _MSC_VER
-#else
+#if !defined(_MSC_VER) && !defined(__FreeBSD__)
cpu = random() % n_cpus;
CPU_ZERO(&cpuset);
CPU_SET(cpu, &cpuset);

Ganon

2017-07-25, 10:09:41

Ein guter "Real-World" Test scheint wohl auch das Compilieren vom OpenJDK zu sein, wenn man dem Tool nicht vertraut.

iuno

2017-07-25, 14:47:05

Kann das Problem auch@stock nachstellen, hat mit meinen OC Settings also nichts zu tun. :uclap:

StefanV

2017-07-27, 22:06:18

http://www.planet3dnow.de/vbulletin/threads/428281-AMD-Epyc-bereits-mit-B2-Stepping-des-Zeppelin-Dies-Update?p=5162190&viewfull=1#post5162190

Hast du mal geschaut, ob bei dir IOMMU, SRIOV aktiv ist??
NUtzt du eigentlich eine AMD oder nVidia Grafikkarte?
Ist ALSR bei dir aktiv??

Ätznatron

2017-07-27, 23:15:16

iuno

2017-07-28, 00:38:28

Kann ich vielleicht irgendwann mal nachschauen, ich gebe aber ehrlich gesagt nichts auf Vermutungen basierend auf einem Tool, das bei mir noch nie einen Fehler produziert hat.

Exxtreme

2017-07-28, 10:05:25

Leute, solche Fehler müssen nicht unbedingt durch CPU-Fehler als Quelle haben. Ein Segfault ist ein Zugriff auf eine Ressource, die zu dem Zeitpunkt vor Zugriffen geschützt ist. Sowas kann auch eine sog. race condition (https://de.wikipedia.org/wiki/Race_Condition) auslösen. Sprich, es kann sein, dass das schlicht ein Bug im GCC ist, der nur unter bestimmten Bedingungen wie bestimmte Taktfrequenzen, Cacheinhalt etc. auftritt.

Ganon

2017-07-28, 10:25:31

Sprich, es kann sein, dass das schlicht ein Bug im GCC ist, der nur unter bestimmten Bedingungen wie bestimmte Taktfrequenzen, Cacheinhalt etc. auftritt.

Tritt halt auch mit Clang auf und laut einem User hier auch mit dem Microsoft Compiler.

roha

2017-07-28, 11:25:27

Also bei mir tritt der Fehler nicht auf, das Testprogramm läuft ohne Fehler. Auch kompiliere ich die git Versionen von Mesa clang und llvm in Schleife ohne jeden Fehler. Das ganze unter Arch Linux testing, mit gcc 7.1.1. Mainboard ist ein MSI 370 Pro Carbon, mit Ryzen 1700x stock, und Gskill TridentZ F4-3200C14D-16GTZ RAM der mit 1600MHZ läuft.

MfG roha

Pirx

2017-07-28, 12:19:02

dein RAM ist zu schnell;)

Isen

2017-07-29, 11:18:17

Backflash auf agesa 1004 gemacht. Fehler weg.
ECC RAM mit 1006 half nichts.

TGKlaus

2017-07-30, 22:38:04

Kann jemand mal genau erläutern, was dieses Programm macht / misst.

Ich hab es jetzt mal das Wochenende auf meinem Firmen Travel-Laptop (Dell XPS 13) laufen lassen und hab bis 38.000 17ngs. (Bis 18.000 war nix)

Isen

2017-07-30, 22:52:33

Aus der Readme:

About]

This is a test code to reproduce SEGV of RYZEN processor (At least in my thought).

[Overview]

This is a "cross-modifying code".
There a three threads (thread1 and two threadx).
Thread1 executes code of specific address repeatedly, at the same time threadx modify data of this address.
The execution and modifing are protected with multithread synchronization and memory barrier.
In addition to this, a serializing instruction is inserted before call of modified function code.

About serializing instruction in "cross-modifying code":
"8.1.3 Handling Self- and Cross-Modifying Code" of
https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html (Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A: System Programming Guide, Part 1)

rpm8200

2017-07-31, 17:15:00

[...]Ich hab es jetzt mal das Wochenende auf meinem Firmen Travel-Laptop (Dell XPS 13) laufen lassen und hab bis 38.000 17ngs. (Bis 18.000 war nix)Hat der nicht nen Core i7 Prozessor? Ich dachte das Problem wäre Ryzen spezifisch? Wenn es auf anderen CPUs auch auftritt und nicht Ryzen exklusiv, dann vermute ich eher einen Software Bug?

TGKlaus

2017-07-31, 22:44:46

Ja, einen i7-U.
Deshalb die Frage, was genau das Programm macht.

Auf unsere Ryzen Workstations (1700X, ASUS Prime B350-Plus) mit win10 gibts auch diese "Fehler".

Mit dem alten win7 client beim Test heute nicht. Läuft die Nacht weiter, mal sehen was bis morgen so passiert ist.

Conner_Ray

2017-08-01, 13:38:59

Hört sich für mich immer mehr danach an dass dieser Test ungeeignet ist um einen angeblichen Hardwarebug im Ryzen zu verifizieren.......

Darkman.X

2017-08-01, 19:56:15

Soweit ich verstanden habe, deckt der Test auch instabiles OC / RAM-Timings / Cache auf. Deshalb zeigt der Test auch bei Intel-CPUs Fehler.

Ätznatron

2017-08-01, 20:39:35

Alles zu inkonsistent, belastbare Schlüsse aus einem Ablauf dieses Programms lassen sich IMHO nicht ziehen.

Exxtreme

2017-08-01, 20:57:23

Ja, einen i7-U.
Deshalb die Frage, was genau das Programm macht.

Also so wie ich das sehe wird in einem Thread Code ausgeführt und ein anderer Thread versucht diesen Code zu modifizieren. Die Modifikation wird aber wiederum durch einige atomic-Funktionen/Datentypen geschützt. Wird der auszuführende Code aber doch verändert dann wirft das Programm Zugriffsverletzungen.

Jetzt stellt sich halt die Frage durch was diese Veränderungen kommen. Es können natürlich Fehler in der CPU sein, aber auch Fehler im Compiler, Fehler in den Bibliotheken, Fehler in der selbstgebastelten Speicherbarriere etc.

Ich persönlich gebe nicht viel auf diesen Test.

Edit: So wie es aussieht ist das nicht einmal eine echte Speicherbarriere sondern der Autor deaktiviert lediglich Out-of-order-Execution mit "asm volatile("mfence":::"memory")". Hmmm, leider habe ich null Erfahrung mit so Low-Level-C-Zeugs. Aber ich würde definitiv nichts auf diesen Test geben.

w0mbat

2017-08-02, 09:37:40

https://www.reddit.com/r/Amd/comments/6qyz83/threadripper_early_adopters_and_ryzen_gamers_can/

Hier gibt es mehr zum Thema, da liest auch AMD mit.

TGKlaus

2017-08-04, 11:42:12

Bei uns ist nun eine Menge mit dem "Testprogramm" "rumgespielt" worden.

2 Erkenntnisse lassen sich klar ableiten:

1. die Fehler treten nicht Ryzenspezifisch auf, Sie passieren genauso auf Skylake und Haswell Prozessoren (unsere neuen Laptop und Clients vs unsere Alten)

2. unter win7 gibt es DEUTLICH weniger Fehler (nicht nur bei baugleichen Systemen, sonderen 2 wurden extra "plattgemacht" und win 7 drauf installiert)

iuno

2017-08-05, 03:32:22

Michael Larabel von Phoronix hat sich der Sache jetzt auch mal angenommen: https://phoronix.com/scan.php?page=news_item&px=Ryzen-Test-Stress-Run

Vielleicht gibt es demnaechst auch mal mehr zum Thema und AMD sieht sich genoetigt eine Stellungnahme abzugeben. Fuer die Verhaeltnisse dort sind auch schon relativ viele Kommentare im Forum.

Isen

2017-08-05, 10:03:19

Die Boardpartner können sich dann auch gleich dazu gesellen, komplette 250k Loop ging ohne Segfault bei mir durch, nur weil ich aufs Auslieferungs Bios zurück geflasht habe (agesa 1004)

Ganon

2017-08-05, 10:19:51

Vielleicht gibt es demnaechst auch mal mehr zum Thema und AMD sieht sich genoetigt eine Stellungnahme abzugeben. Fuer die Verhaeltnisse dort sind auch schon relativ viele Kommentare im Forum.

Leider auch immer sehr viele Meta-Diskussionen. Also statt dass das Problem von allen mal einfach untersucht wird, wird tendenziell erst mal die Schuld irgendwem anders gegeben. Gut, ist ja hier nicht anders gewesen. Lustig auch überall die gleiche (falsche) Leier (tritt nur in GCC auf, Windows nicht betroffen, Linux-Only Problem, pi pa po).

Viele verstehen auch das Prinzip der Wahrscheinlichkeit scheinbar nicht. Mit dem Ändern diverser Systemparameter (ASLR, Memory-Timings, SMT, ...) ändert man eben vermutlich nur die Wahrscheinlichkeit, dass das System den Fehler triggert. Es behebt ja nicht das grundlegende Problem an sich.

Im Endeffekt kann man im jetzigen Zustand eh nur noch auf AMD warten. Die kennen das Problem und vermutlich werden auch die ein Projekt einfach mal in einer Schleife dauerkompiliert kriegen. Denn das Problem ist weiterhin: Es ist mit Ryzen nicht möglich große Projekte dauerhaft stabil zu kompilieren.

Ätznatron

2017-08-05, 11:06:20

Denn das Problem ist weiterhin: Es ist mit Ryzen nicht möglich große Projekte dauerhaft stabil zu kompilieren.

Tatsächlich?

Das glaube ich nicht. Aber ich will ja auch nicht auf Teufel komm raus ein mögliches Problem großreden.

Ganon

2017-08-05, 11:41:13

Tatsächlich?

Jup. Unter FreeBSD z.B. baut man in der Regel seine Software selbst. Wie du in der Mailing Liste von FreeBSD nachlesen kannst (erste 1-2 Seiten irgendwo) haben die Entwickler die ein Ryzen System haben schon Probleme das OpenJDK zu bauen. Das machen die nicht erst seit Ryzen, das machen die schon über Jahrzehnte so.

Genauso macht dieser Phoronix Stress Test nichts anderes als vollkommen normale Software zu kompilieren. Auch der Reddit-Thread macht nichts anderes als den GCC zu bauen.

Ergebnis: Mit ziemlich hoher Wahrscheinlichkeit kracht es auf Ryzen. Bei einigen nach ein paar Sekunden, bei anderen nach ein paar Stunden. Typisches Problem bei Race Conditions, man weiß nie wann es auftritt.

Das glaube ich nicht. Aber ich will ja auch nicht auf Teufel komm raus ein mögliches Problem großreden.

Du kannst glauben was du willst, aber probiere es doch aus. Sämtliche Software ist frei verfügbar.

Dieses Tool von github ist nicht anderes als ein Versuch das Problem "simpel" nachzustellen. Jetzt auf dem Tool alleine rumzuhacken bringt nichts, denn das Problem gab es schon vor dem Tool und auch weiterhin.

Ätznatron

2017-08-05, 11:49:03

Das mag alles sein, auf meinem Intel-Rechner laufe ich mit dem Tool trotzdem über kurz oder lang in die gleiche Fehlerproblematik, ob mit OC oder ohne.

Was FreeBSD anbelangt: Mit gleichem Recht kann ich einen seit Jahrzehnten unentdeckt gebliebenen Software-Bug vermuten, den Ryzen an den Tag gebracht hat.

Ganon

2017-08-05, 12:15:01

Das mag alles sein, auf meinem Intel-Rechner laufe ich mit dem Tool trotzdem über kurz oder lang in die gleiche Fehlerproblematik, ob mit OC oder ohne.

Darum sagte ich ja schon Anfangs: Wenn man dem Tool nicht vertraut, mache bitte echte Tests.

Was FreeBSD anbelangt: Mit gleichem Recht kann ich einen seit Jahrzehnten unentdeckt gebliebenen Software-Bug vermuten, den Ryzen an den Tag gebracht hat.

Ein Bug der unter Linux, FreeBSD, NetBSD, DragonFly BSD, Windows, GCC, Clang, dem Microsoft Compiler und generell überall auftritt und nicht bei älteren AMD CPUs und Intel CPUs und allen alternativen non-x86 CPUs ist also ein langjähriger Software Bug?

Ich mein... come on... man kann ein Problem auch mal nüchtern und objektiv betrachten. Die meisten Leute wollen nicht Ryzen oder AMD schlecht machen, sondern sie wollen einfach, dass der Bug behoben wird.

iuno

2017-08-05, 13:26:42

Tatsächlich?
Hast du Ryzen? Bau halt mal llvm. Mit Sandy und Skylake kein Problem bei mir (und aufkrawall), bei Ryzen kracht es relativ sicher.

Und bei mir hat das Tool wie schon mehrfach gesagt ueberhaupt keine Fehler geworfen.

Lehdro

2017-08-05, 15:28:47

Ich hab jetzt extra mal mein Zweitsystem angeworfen, i5 2500k @ 4,7 GHz. Ergebnis: Segfault.
Dann BIOS zurückgesetzt und nochmal: Segfault. Kamen jedes mal recht fix.

Meinen Ryzen habe ich noch nicht getestet, keine Chance den mal paar Stunden für sowas herzugeben.

iuno

2017-08-05, 16:13:48

Bei welchem use case?
Sollte man schon dazu schreiben. Diverse Testtools sind imho voellig uninteressant wenn sie im Bezug auf "produktive" workloads sowohl false positives bringen als auch auf einem nicht 100% funktionierenden System keine Fehler schmeissen. Und dann ist das Ding auch noch hart uebertaktet, sorry, aber Thema verfehlt und keine Relevanz.

Skysnake

2017-08-05, 16:19:07

Wobei das an sich irrelevant sein sollte.

Es ist schon etwas strange, wobei ich mich noch nicht mit der Thematik beschäftigt habe um zu schauen ob das jetzt richtig implementiert wurde oder nicht.

Interessant ist das Thema aber auf jeden Fall

Ganon

2017-08-05, 16:23:00

Lehdro

2017-08-05, 16:24:27

Bei welchem use case?
Und dann ist das Ding auch noch hart uebertaktet, sorry, aber Thema verfehlt und keine Relevanz.

Was verstehst du an BIOS zurückgesetzt nicht? ->Stock, das betrifft ALLES.

Ich halte von dem Tool nicht viel, da es nun bei mehreren NON-Ryzen Systemen genau dasselbe aufgezeigt hat. Mag sein das beim Compilen mit Ryzen was arg schief läuft, aber das Tool ist nicht der Weisheit letzter Schluß, da es bei enigen Fehler wirft die eben KEINE Ryzen haben:

Thinkpads Workstation Laptops also alle Fehlerhaft? Willst du das damit sagen?

Ich hab es jetzt mal das Wochenende auf meinem Firmen Travel-Laptop (Dell XPS 13) laufen lassen und hab bis 38.000 17ngs. (Bis 18.000 war nix)

1. die Fehler treten nicht Ryzenspezifisch auf, Sie passieren genauso auf Skylake und Haswell Prozessoren (unsere neuen Laptop und Clients vs unsere Alten)
Das mag alles sein, auf meinem Intel-Rechner laufe ich mit dem Tool trotzdem über kurz oder lang in die gleiche Fehlerproblematik, ob mit OC oder ohne.

Skysnake

2017-08-05, 16:41:27

Der oben verlinkte Reddit-Thread (https://www.reddit.com/r/Amd/comments/6qyz83/threadripper_early_adopters_and_ryzen_gamers_can/) gibt eigentlich eine ziemlich einfache Anleitung für Leute die dem anfangs verlinkten Test-Tool nicht vertrauen.

Hier kann man auch gerne sein Intel-System testen... wenn es hier zum Crash kommt ist wirklich was kaputt. Und diesem "Test" (was kein Test ist sondern ein Real-World Szenario) kann man nun wirklich nichts vorwerfen.

Hier steigt Ryzen eben zuverlässig aus. Bei einigen nach ein paar Sekunden/Minuten, bei anderen nach ein paar Stunden. Wer will kann das auch gerne im Linux Subsystem für Windows machen (ab Punkt 11) und berichten. Ist aber durchaus möglich, dass man hier noch ein bisschen was nachinstallieren muss.
Ich habe mir mal den Code runter geladen und da war auch binär code wohl dabei wenn ich das richtig gesehen habe. Der Testberichte ist auf jeden Fall kein 10 Zeilen Programm. Da kann sich leicht ein Fehler einschleichen.

Habe ich selbst erst neulich in einem eigenen Testprogramm erlebt. An sich total einfach und dutzende male auf den Code geschaut. Den Fehler aber erst beim code refactoring gesehen....

Und bei solchen Sachen wie memory fences etc. Muss man schon sehr aufpassen, was nun wirklich garantiert ist und was nur die meisten CPUs auf eine bestimmte weiße machen.

Wenn man in die Vergangenheit schaut, dann ist es schon öfters passiert, das man über viele Jahre an sich falschen code verwendet hat, weil der Fehler eben nicht auf den CPUs auftreten konnte.

Ich Maße mir nicht an sagen zu können ob das jetzt ein Software oder Hardware Problem ist. Und falls es ein Hardware Probleme ist, dann ist das im allgemeinen sehr schwer herauszufinden was den Fehler auslöst. Im allgemeinen sind das ziemlich komplexe Randbedingungen.

iuno

2017-08-05, 16:50:23

Ich halte von dem Tool nicht viel
Ich auch nicht, wie bereits gesagt. Ich kann es auch noch 100x schreiben, das bringt aber genausowenig wie diejenigen aufzuzaehlen, die andere Ergebnisse hatten.

Und obwohl du nichts davon haeltst, testest du es in drei verschiedenen Konfigurationen, willst aber keine 20 Minuten fuer einen richtigen build Test Zeit haben?

Ganon

2017-08-05, 16:52:56

Ich Maße mir nicht an sagen zu können ob das jetzt ein Software oder Hardware Problem ist. Und falls es ein Hardware Probleme ist, dann ist das im allgemeinen sehr schwer herauszufinden was den Fehler auslöst. Im allgemeinen sind das ziemlich komplexe Randbedingungen.

Das mag ja durchaus sein... aber es tritt auf unterschiedlichen Betriebssystemen und unterschiedlichen Compilern auf die allesamt nicht voneinander abstammen und es ist auch ziemlich egal ob man nun GCC, LLVM oder das OpenJDK baut.
Das hier sämtliche Projekte ein und denselben Fehler gemacht haben, der über sämtliche CPU-Architekturen hinweg nicht auftritt, aber genau nur auf Ryzen wäre doch schon sehr arg unwahrscheinlich, dass es ein Bug in sämtlicher Software auf der Welt wäre und nicht in Ryzen.

Zumal der DragonFly BSD Entwickler bereits im April einen deterministischen Testcase an AMD geschickt hat, von zumindest einem Problem. Das ist halt nur kein Test, den man mal eben ausführen kann, da Kernel-Code. Ob das mit dem "Compiler Bug" zusammenhängt ist halt die nächste Frage dabei.

Conner_Ray

2017-08-05, 17:03:42

aber es tritt auf unterschiedlichen Betriebssystemen und unterschiedlichen Compilern auf die allesamt nicht voneinander abstammen
Ich hatte das ja schonmal gefragt, was denn so besonders am compilieren ist, da ich mich da nicht auskenne. Die Antworten waren ja: eigentlich nichts besonderes, halt viel IO, viel RAM-schreiberei etc.

Oder gibt es doch CPU-Befehle die nur beim compilieren benutzt werden?

wenn nicht; ein Hardware-Bug im Ryzen müsste dann doch auch beim Ausführen von "normalem" Programmcode zu Fehlern führen? Bei den zig-hunderdtausenden von Programmen im Win und Linux-Umfeld?

Ganon

2017-08-05, 17:16:02

Ich hatte das ja schonmal gefragt, was denn so besonders am compilieren ist, da ich mich da nicht auskenne. Die Antworten waren ja: eigentlich nichts besonderes, halt viel IO, viel RAM-schreiberei etc.

Oder gibt es doch CPU-Befehle die nur beim compilieren benutzt werden?

wenn nicht; ein Hardware-Bug im Ryzen müsste dann doch auch beim Ausführen von "normalem" Programmcode zu Fehlern führen? Bei den zig-hunderdtausenden von Programmen im Win und Linux-Umfeld?

Es wurde (dir) auch schon im Thread beantwortet. Kompilieren verwendet zwar nicht eigene Befehle, aber durchaus eine Form von Algorithmen die so normal nicht auftreten.

Es ist ja nicht nur kompilieren, nur ist eben die 08/15 Software da draußen in der Welt nicht so intensiv.

Es passieren auch anderweitig seltsame Dinge. DragonFly BSD und FreeBSD (beide verwandt) z.B. stürzen auf Ryzen auch einfach mal so komplett ab. Man hat da erkannt, dass Ryzen bei bestimmten Speicherkonstellationen einfach Unsinn fabriziert (hardlock innerhalb der CPU) und man hat mittlerweile Ryzen-spezifische (CPUID Abfrage) Workarounds eingebaut, die diese Speicherkonstallation verhindern, damit das OS nicht mehr (oder nicht mehr so oft, weiß man ja nie) einfach komplett abschmiert. Das "Compiler-Problem" ist damit aber nicht gelöst.

Das massive Kompilieren von Software ist halt nur die einfachste Form das Problem mal eben so zu triggern. Dabei wurde das Problem letztendlich auch entdeckt.

Exxtreme

2017-08-05, 17:18:03

Oder gibt es doch CPU-Befehle die nur beim compilieren benutzt werden?

Unwahrscheinlich. Denn Compiler werden ebenfalls kompiliert und damit wie jedes andere Programm auch behandelt. Es sei denn, der Compiler-Sourcecode würde Inline Assembler-Befehle enthalten, die ein Compiler selbst nicht benutzt. Das ist aber schon ein sehr konstruiertes Szenario. Damit wäre aber sowas möglich.

Conner_Ray

2017-08-05, 17:30:18

Es wurde (dir) auch schon im Thread beantwortet. Kompilieren verwendet zwar nicht eigene Befehle, aber durchaus eine Form von Algorithmen die so normal nicht auftreten.

Es ist ja nicht nur kompilieren, nur ist eben die 08/15 Software da draußen in der Welt nicht so intensiv.

Es passieren auch anderweitig seltsame Dinge. DragonFly BSD und FreeBSD (beide verwandt) z.B. stürzen auf Ryzen auch einfach mal so komplett ab. Man hat da erkannt, dass Ryzen bei bestimmten Speicherkonstellationen einfach Unsinn fabriziert (hardlock innerhalb der CPU) und man hat mittlerweile Ryzen-spezifische (CPUID Abfrage) Workarounds eingebaut, die diese Speicherkonstallation verhindern, damit das OS nicht mehr (oder nicht mehr so oft, weiß man ja nie) einfach komplett abschmiert. Das "Compiler-Problem" ist damit aber nicht gelöst.

Das massive Kompilieren von Software ist halt nur die einfachste Form das Problem mal eben so zu triggern. Dabei wurde das Problem letztendlich auch entdeckt.
Danke für die Erklärung. Versteh mich aber auch bitte nicht falsch, ich will mit meiner Nachfrage nicht Ryzen "verteidigen", sondern versuchen zu verstehen warum der Bug bisher nur beim compilieren auftritt.
Es war für mich nur schwer verständlich, weil bei der riesigen Menge an Software in der Welt, von Games zu Office, zu wissenschaftlichen Programmen zum BOINC-crunchen zu etc etc dieser Fehler (bisher?) nicht auftritt....

Ganon

2017-08-05, 17:51:51

Es war für mich nur schwer verständlich, weil bei der riesigen Menge an Software in der Welt, von Games zu Office, zu wissenschaftlichen Programmen zum BOINC-crunchen zu etc etc dieser Fehler (bisher?) nicht auftritt....

Sind halt aber auch nicht gerade sehr intensive Workloads. Bei BOINC und anderen wissenschaftlichen Anwendungen wäre interessant wie viele da eigentlich schon den Ryzen für einsetzen (gibt ja auch genug GPU-Cores). Ansonsten wird man vermutlich mit einem eher "stabilen", oder sagen wir mal "Cache-freundlichen" Workload dieses Problem nicht triggern können.

Massives Kompilieren sind halt sehr viele Kontext-Wechsel zwischen Kernel und Userland (hier fallen schon mal viele Userland-Anwendungen raus), es ist sehr datenintensiv und verarbeitet auch immer unterschiedliche Daten mit unterschiedlichen Operationen und nicht "rechte mal diese ganzen Daten bitte alle mal zwei" (so doof gesagt).

AMD weiß halt auch schon lange bescheid und nimmt auch keine Support-Anfragen oder Hinweise dazu an, soweit ich weiß. Von daher kann man hier halt echt nur auf ein offizielles Statement warten. Alles was jetzt so passiert ist im Endeffekt nur noch dazu da, um zu zeigen dass das Problem real ist und keine Verschwörung von Intel-Fanboys oder sonst was.

StefanV

2017-08-05, 17:53:28

Das mag ja durchaus sein... aber es tritt auf unterschiedlichen Betriebssystemen und unterschiedlichen Compilern auf die allesamt nicht voneinander abstammen und es ist auch ziemlich egal ob man nun GCC, LLVM oder das OpenJDK baut.
Das hier sämtliche Projekte ein und denselben Fehler gemacht haben, der über sämtliche CPU-Architekturen hinweg nicht auftritt, aber genau nur auf Ryzen wäre doch schon sehr arg unwahrscheinlich, dass es ein Bug in sämtlicher Software auf der Welt wäre und nicht in Ryzen.
Wenn alle Compiler Programmierer zur selben Schule gingen oder die selben Mailinglisten aboniert haben und einen ähnlichen Code implementiert haben??

AMD wird das ganze wohl selbst noch untersuchen, DESWEGEN werden sie sich nicht dazu äußern, bevor sie nicht wissen, was die Ursache ist.

Und die ganzen "Diskussionen" hier und den ganzen anderen Bereichen sind auch wenig hilfreich, da unsachlich...
Theorien und Vermutungen helfen hier gerade einfach mal überhaupt nicht. Alles was hilft ist, was zu kompilieren, das System bis ins kleinste Detail aufzulisten und das dann an einem Ort ablegen, an dem es AMD auch sehen kann.

Alles andere bringt einfach nichts....

Lehdro

2017-08-05, 18:03:29

Und obwohl du nichts davon haeltst, testest du es in drei verschiedenen Konfigurationen, willst aber keine 20 Minuten fuer einen richtigen build Test Zeit haben?
Wieso denn 3? Es waren 2 auf einem _anderem_ System und _nebenbei_ um herauszufinden was das mit dem Tool so auf sich hat.
Ich brech jetzt sicher nicht auf meinem Hauptsystem alles andere ab nur um zu testen was damit passiert: Es kommt eh ein segfault. Das interessiert mich aber null da ich nicht kompiliere. Was mich aber interessierte war ob das Tool was taugt, was es aber eben nicht tut. Das kam hier vorher nicht so für mich rüber.

Skysnake

2017-08-05, 18:18:25

Das mag ja durchaus sein... aber es tritt auf unterschiedlichen Betriebssystemen und unterschiedlichen Compilern auf die allesamt nicht voneinander abstammen und es ist auch ziemlich egal ob man nun GCC, LLVM oder das OpenJDK baut.
Das hier sämtliche Projekte ein und denselben Fehler gemacht haben, der über sämtliche CPU-Architekturen hinweg nicht auftritt, aber genau nur auf Ryzen wäre doch schon sehr arg unwahrscheinlich, dass es ein Bug in sämtlicher Software auf der Welt wäre und nicht in Ryzen.

Zumal der DragonFly BSD Entwickler bereits im April einen deterministischen Testcase an AMD geschickt hat, von zumindest einem Problem. Das ist halt nur kein Test, den man mal eben ausführen kann, da Kernel-Code. Ob das mit dem "Compiler Bug" zusammenhängt ist halt die nächste Frage dabei.

Du wirst lachen, aber so etwas passiert durchaus. In MPI gab/gibt es solche Probleme, weil man irgendwann mal irgend einen Mist gefiederten hat bzw sich auf gewisse Annahmen gestützt hat. Gerade was Threading anbelangt muss man schon aufpassen.

Ich hatte z.b. Vor kurzem mit einem code zu tun, bei dem der intel compiler nachweislich mit openmp falsche Ergebnisse generiert hat.

Wie gesagt. Die Dinge sind wirklich nicht einfach. Daher AMD Abs Bein zu pinkeln ist nicht zielführend.

Erinnert ihr euch noch an den tlb bug oder den Intel sata gate bug oder den floating pointiert bug oder den tsx bug, der sogar zur Streichung des Feature in einer kompletten Generation geführt hat?

Ganon

2017-08-05, 18:27:16

Erinnert ihr euch noch an den tlb bug oder den Intel sata gate bug oder den floating pointiert bug oder den tsx bug, der sogar zur Streichung des Feature in einer kompletten Generation geführt hat?

Waren halt alles Hardware-Bugs ja und keine Software-Bugs.

Und wie gesagt... es ist kein Rätselraten wo der Fehler so überhaupt liegt. Es ist durchaus bekannt, bzw. offensichtlich, dass die CPU selbst hier Mist macht. Das was der DragonFly BSD Entwickler im Kernel zur CPU geschickt hat und das was die CPU daraufhin getan hat war schlicht falsch. Da gibt es nicht viel drum rum zu diskutieren. Ich meine... es war ein Hardlock in der CPU... die CPU hat schlicht aufgehört Dinge zu tun...

Auch der GCC stürzt nicht einfach nur immer ab und man weiß nicht was Sache ist. Der GCC steigt u.a. auch aus, weil die CPU intern eine Exception wirft, dass er die eigene Instruktion nicht mehr kennt.

Also nehmt es mir nicht übel wenn ich die Annahme "sämtliche Compiler auf der Welt sind kaputt und Ryzen hat es aufgedeckt" nicht ganz so für wahrscheinlich halte.

Skysnake

2017-08-05, 18:34:01

Es kann aber bisher keiner sagen, von welchen Randbedingungen es abhängt. Kann auch gut sein das es mit Pcie atomics oder sonst was zusammenhängt.

Es klingt für mich auch erstmal eher nach einem Hardware bug aber ich würde mich hüten das als gesichert zu setzen. Kann auch an irgend einem Treiber liegen der bei Interrupts einen Fehler verursacht. Oder an der Art und Weise der dynamischen Taktänderung. Wer weiß vielleicht ändert man etwas zu optimistisch die Frequenzen oder was weiß ich. Es gibt eine Millionen möglicher Ursachen, von denen man wohl die meisten der BIOS micro code update gefixt bekommt.

Wie gesagt, der ich sollte auch nicht einfach falsche Ergebnisse liefern wenn man mit openmp compiliert. Hat er aber getan. Ist halt alles Software. Also selbst in CPUS und GPUS ist verdammt viel Software drin

Ganon

2017-08-05, 18:40:15

Wie gesagt, der ich sollte auch nicht einfach falsche Ergebnisse liefern wenn man mit openmp compiliert. Hat er aber getan. Ist halt alles Software. Also selbst in CPUS und GPUS ist verdammt viel Software drin

Ja Compiler haben durchaus auch Bugs, ja. Aber das Problem tritt ja eben über mehrere Compiler hinweg auf und nun einfach anzunehmen, dass sämtliche Compiler den gleichen Bug haben ist... unwahrscheinlich. Gerade bei diesem Fehlerbild.

Skysnake

2017-08-05, 18:47:31

Wie gesagt, ich stimme dir da zu, aber ausschließen würde ich es dennoch nicht.

Wenn man sich anschaut was man alles in Assembler machen muss um funktionierenden code zu bekommen wird mir schon angst und bange.

Und wie gesagt es ist schwierig zu sagen was jettözt Software und was Hardware ist. Ist ja nicht so das compiler nicht in einem OS laufe würden.

Ps: gutes Beispiel für kaputte Software sind Filesysteme. Da kann es auch mal passieren das über Jahre Fehler drin sind die zu Datenverlusten führen. Oder bei Updates plötzlich Dateien 0 bytes groß sind....

Über so was hört man aber oft auch nicht viel weil es nur unter sehr speziellen Randbedingungen mit großen Systemen auftritt.

Gut nen Ryzen ist nicht sooooo fancy, aber das XFR Feature und die CCX sind schon "interessant "

Ganon

2017-08-05, 18:52:59

Jojo, ich will jetzt auch nicht die Diskussion ins unendliche ziehen, aber "Bug in einzelner Software der auf jeder Hardware auftritt" vs. "Bug der mit aller Software auf einzelner Hardware auftritt" sind schon unterschiedliche Dinge und zeigen hier schon, wo das Problem liegt.

Aber ja, beide Standpunkte sind nun vermutlich klar. Warten wir auf AMD.

Naitsabes

2017-08-05, 18:53:31

Ohne überhaupt eine Ahnung zu haben was da genau passiert, aber wie sieht es mit Bitflips aus? Können die zu so einem verhalten führen?
Dass Ryzen eine Speicherzicke sein kann, ist ja kein Geheimnis. Tritt der Fehler also auch bei bei Epycs mit ECC Ram auf?

Ganon

2017-08-05, 18:59:33

Tritt der Fehler also auch bei bei Epycs mit ECC Ram auf?

Er tritt auch mit ECC RAM auf, ja. Zu lesen u.a. auf der FreeBSD Mailing-Liste.

Skysnake

2017-08-05, 19:10:22

Naja, es ist soweit ich die Diskussion mitbekommen habe eben nicht so das es nur mit Ryzen auftritt, sondern auch mit Intel Systemen. Wobei mir nicht klar ist ob es nur mit oc auftritt oder auch ohne. Die Aussagen sind da irgendwie sehr widersprüchlich

Ganon

2017-08-05, 19:13:42

Naja, es ist soweit ich die Diskussion mitbekommen habe eben nicht so das es nur mit Ryzen auftritt, sondern auch mit Intel Systemen.

Dabei geht es um einen einzelnen Test den es auf github gibt. Das "kompileren von Software in einer Dauerschleife" ist ein Ryzen-Only Problem und tritt bei einem Non-Ryzen System nicht auf. Mal angenommen man hat nicht instabil übertaktet.

aufkrawall

2017-08-05, 19:28:28

Skysnake

2017-08-05, 19:39:38

Naja aber compilieren von echter Software ist ein Speichertest und wird wohl mit turboboost laufen.

Kann also durchaus auch einfach ein fehlerhaftes Binning sein. Natürlich nicht gut, aber damit hatte sogar das ORNL mit ihren GPUs zu kämpfen. Da gab es eine Hand voll von Karten die viel viel mehr Speicherfehler erzeugt haben als alle anderen. Die hatten darüber auch ein paper geschrieben. Hat recht lange gedauert bis sie das herausgefunden haben.

Wie gesagt so was in die Richtung kann ich mir sogar recht gut vorstellen. Wie ja auch andere schon gesagt haben ist Ryzen ja durchaus bekannt dafür zickig beim Speicher zu sein.

Man hat die Systeme der Leute mit Problemen halt nicht zur Hand und es tritt ja offenkundig auch nicht bei allen auf. Vor allem hat ja anscheinend zumindest bei einem ein downgrade vom BIOS etwas gebracht. Ich meine zumindest das schon hier gelesen zu haben.

Was halt nicht geht ist sich hier über AMD aus zu lassen und zu sagen denen wäre das scheißegal.. Die werden schon danach schauen, aber so einfach wie sich das einige vorstellen ist das auch nicht. Vor allem wenn es wirklich Problem mit Timing bzw Fertigungstolleranzen ist.

Da gibt es kein schwarz und weiß mehr. Ist das Binning fehlerhaft, oder das Design an sich? Oder sind die Parameter in der Firmware falsch? Oder hat man was am Package versammelt oder ist es ein Problem mit den boards bzw dem RAM?

Die Grenzen sind da fließend und manchmal funktioniert auch alle wie es soll, aber man hat etwas bei der Definition der specs übersehen. Ich sag man nur Pcie 3.0 einführung

Ganon

2017-08-05, 19:41:13

"Schön" (eigentlich eher unschön) ist, dass er einen kompletten Lockup des Systems, wie es bei DragonFly/FreeBSD auftreten konnte, auch unter Linux nachvollzogen hat.

Ich hoffe echt AMD kriegt das mit einem Microcode Update gefixt. Manche sagen ja auch, dass es in den neusten BIOS Updates eine Möglichkeit gibt den neuen micoOp Cache zu deaktivieren. Mal gucken ob Phoronix das die nächsten Tage auch mal testet.

Was halt nicht geht ist sich hier über AMD aus zu lassen und zu sagen denen wäre das scheißegal..

Huh? Das tut doch niemand ernsthaft? Aber ihre Kommunikation nach außen hin könnte besser sein.

herp_derp

2017-08-05, 19:49:49

https://www.reddit.com/r/Amd/comments/6rmq6q/epyc_7551_mining_performance/

Segfaults auch bei Epyc, B2 hilft offenbar nicht.

aufkrawall

2017-08-05, 19:52:24

"Schön" (eigentlich eher unschön) ist, dass er einen kompletten Lockup des Systems, wie es bei DragonFly/FreeBSD auftreten konnte, auch unter Linux nachvollzogen hat.

Jetzt musst du aber auch dazu schreiben, warum das die Schuld von der CPU ist und nicht vom Compiler/Linux, sonst wird nämlich die Theorie hier von den üblichen Relativierern wieder aufgekocht. ;)
Ich denke mal, es wird wohl daran liegen, dass durch den CPU-Fehler in für den Compiler nicht vorgesehene Speicherbereiche geschrieben wurde, die etwa schon vom Kernel besetzt waren, und dann knallt es halt richtig.

Ich hoffe echt AMD kriegt das mit einem Microcode Update gefixt.
Irgendeine Kommunikation wäre mal schön. Die Zeitspanne, zwischen der Debian das letzte HTT-Problem bei Intel publik (und Intel das gleich offiziell bestätigte, wenn vielleicht auch nicht unbedingt klarstmöglich) machte, und seitens Intel der Fix verteilt wurde, war bereits Stand Jetzt schon viel kürzer als das Ryzen-Problem.
Erschien mir btw. nicht unwahrscheinlich, dass das so laufen würde. Auch deshalb fühlt es sich gut an, den Ryzen losgeworden zu sein. Einfach ohne Sorge kompilieren zu können...

Skysnake

2017-08-05, 19:52:31

http://www.phoronix.com/scan.php?page=article&item=ryzen-segv-continues&num=1
Haben die etwa versäumt, in der Validierungsphase mit frühem Silizium Kompilier-Stresstests zu fahren? Das wär, auf Neudeutsch, schon ziemlich fail.
Hmm interessant.

Aber er sollte mal den performance governor auf performance stellen und die Frequenzen so wählen das man immer die gleichen Taktrate hat.

Dann könnte man mal schauen ob es ein Problem mit dem hin und her getaktet ist.

Unter Linux gab es da auch mit Intel Probleme in letzter Zeit. Ich glaub es waren nur performance Probleme aber sicher bin jch mir nicht. Da gab es auch mal das Problem das intel CPUS nicht mehr aus dem Idle hoch kamen.

Exxtreme

2017-08-05, 19:54:35

http://www.phoronix.com/scan.php?page=article&item=ryzen-segv-continues&num=1
Haben die etwa versäumt, in der Validierungsphase mit frühem Silizium Kompilier-Stresstests zu fahren? Das wär, auf Neudeutsch, schon ziemlich fail.
Das muss, wie schon geschrieben nicht unbedingt ein CPU-Bug sein. Es kann z.B. sein, dass eine Operation zu schnell oder langsam ausgeführt wird. Dann gibt es eine race condition und die endet dann in einer Zugriffsverletzung. So eine Problematik hatte z.B. Windows 98 wenn man das auf einem K6-2 ab 350 MHz betrieben hat. Da bootete das System nicht weil die CPU eine Warteschleife viel zu schnell ausgeführt hat.

Näheres erfährt man wenn AMD Infos rausrückt. Und derzeit bekleckern sie sich nicht mit Ruhm so wie sie agieren.

aufkrawall

2017-08-05, 19:55:36

Der Takt sollte überhaupt keine Rolle spielen für Crashes, denn das OS kann die Spannung für die Taktstufen nicht beeinflussen. Das wärs ja auch noch.
Wird mit performance genau so/ähnlich auftreten. Und Intel hat einen eigenen Treiber für den Governor, AMD nicht (was btw. auch ein Nachteil für AMD auf Linux ist).
Und das OS hat eh nur begrenzten Einfluss darauf, was die CPU intern für Taktraten nutzt.

Skysnake

2017-08-05, 20:01:45

Und der intel governor ist Müll und wurde teilweise wieder rausgepatcht weil es massiv Probleme mit dem gibt...

Und die CPU kann eben beeinflussen welcher pstate gewählt wird etc.

Klar das kann nicht beeinflussen welche Spannung anliegt aber wenn es ein Binning Problem ist dann kann man das so umgehen. Ist doof aber wäre aber ein minimales Problem

aufkrawall

2017-08-05, 20:06:58

Und der intel governor ist Müll und wurde teilweise wieder rausgepatcht weil es massiv Probleme mit dem gibt...

Komplett falsch. intel-pstate performance ist der einzige Governor für Linux, der Runtertakten zum Energiesparen mit maximaler Leistung kombiniert. Deshalb nutzt Intel den mittlerweile auch für ihr Clear Linux. Und du irrst dich auch damit, dass intel-pstate in irgendeiner nennenswerten Distribution rausgeflogen wäre.
Bei AMD darfst du schön zwischen cpufreq schedutil und performance händisch hin und her schalten, was ziemlich steinzeitlich ist.
Ich hab sowohl mit Sandy Bridge, Ryzen als auch Skylake verschiedene Governors gebenchmarkt und CPU-Videodecoding auf Framedrops getestet. ;)

Und die CPU kann eben beeinflussen welcher pstate gewählt wird etc.

Klar das kann nicht beeinflussen welche Spannung anliegt aber wenn es ein Binning Problem ist dann kann man das so umgehen. Ist doof aber wäre aber ein minimales Problem
Ich stimme dir in so weit zu, dass man mit so einem Test ausschließen könnte, dass der Governor eine Rolle spielt.

Gorkon

2017-08-05, 20:08:13

https://www.reddit.com/r/Amd/comments/6rmq6q/epyc_7551_mining_performance/

Segfaults auch bei Epyc, B2 hilft offenbar nicht.

https://www.reddit.com/r/Amd/comments/6rmq6q/epyc_7551_mining_performance/dl7jlr0/

aufkrawall

2017-08-05, 20:10:12

Ist "conftest" ein synthetisches Test-Tool? Wenn ja, heißt das gar nichts.

Skysnake

2017-08-05, 20:12:59

Aufkrawall das kommt von einem HPC Vendor mit zich Systemen in der TOP500. Ich glaub die wissen schon was sie machen.

Und es geht an sich dabei nicht um den governor, sondern darum zu schauen ob das dynamische takten den Fehler verursacht, was durchaus realistisch ist. Nicht ohne Grund aktiviert man während der Evaluation so was erst recht spät.

aufkrawall

2017-08-05, 20:19:56

Aufkrawall das kommt von einem HPC Vendor mit zich Systemen in der TOP500. Ich glaub die wissen schon was sie machen.

Ich glaubs erst, wenn ichs sehe. Außerdem wurde intel-pstate viel umgebaut. Was du gehört hast, kann schon lange veraltet sein.

Und es geht an sich dabei nicht um den governor, sondern darum zu schauen ob das dynamische takten den Fehler verursacht, was durchaus realistisch ist. Nicht ohne Grund aktiviert man während der Evaluation so was erst recht spät.
Das beabsichtigte ich ja auszusagen. Bis auf das mit dem realistisch, imho ist es unrealistisch bzw. der nächste Strohhalm.

Gorkon

2017-08-05, 20:27:01

Ist "conftest" ein synthetisches Test-Tool? Wenn ja, heißt das gar nichts.

Conftest ist irgendein Python-Modul soweit ich das irgendwie rauslese, nagel mich aber bitte nicht darauf fest. What Ganon said ;)

Ansonsten mal ab hier lesen:

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/967382-50-segmentation-faults-per-hour-continuing-to-stress-ryzen?p=967436#post967436

Ich glaube der liebe Michael hat mal wieder vorschnell was zusammengeschustert und treibt mit dem Artikel wieder Säue durchs verkehrte Dorf...is ja nicht das erste Mal :rolleyes:

Ganon

2017-08-05, 20:27:29

Ist "conftest" ein synthetisches Test-Tool? Wenn ja, heißt das gar nichts.

conftest ist ein Programm was dynamisch erzeugt wird, um zu gucken ob die gewählte Compiler-Konfiguration und allgemeine Umgebung in der Lage ist ein lauffähiges Binary zu erzeugen. Macht eigentlich nicht mehr als eine simple "int main()" Funktion zu erzeugen mit den entsprechenden Headern drum rum.

Auch wenn bridgman jetzt einen Fehler dabei finden sollte, erklärt das noch nicht die kompletten System-Lockups. ;)

Dass conftest an sich abschmieren kann ist aber durchaus ein valides Szenario, muss aber AMD bzw jetzt bridgman aber nun mal sagen, was da nun genau kaputt ist.

edit: Ich orientiere mich übrigens weiterhin an den BSDs wo in einem Real-World Run von den üblichen Port-Builds diese einfach fehlschlagen und/oder sich das System dabei komplett aufhängt.

The_Invisible

2017-08-05, 20:27:54

Und wir haben uns schon überlegt mit Ryzen/Threadripper in der Firma einen günstigen Kompiliercluster aufzubauen bzw. entsprechende Workstations zuzulegen... :eek:

Egal jetzt an was das liegt, aber im Hinterkopf zu haben das ein Segfault jetzt Platfform-seitig oder wirklich Programm-seitig auftritt bringt schon großes Kopfzerbrechen mit.

Ich hoffe AMD kann hier bald Klarheit schaffen, solch eine Ungewissheit macht sich sicher nicht gut bei Firmenkunden.

Isen

2017-08-05, 20:42:53

Dann könnte man mal schauen ob es ein Problem mit dem hin und her getaktet ist.

Die Shadow States... hm... doof ist, dass man Ryzen nicht fix takten kann, die Shadow States wirken durchgehend....

Ganon

2017-08-05, 21:49:53

Ich glaube der liebe Michael hat mal wieder vorschnell was zusammengeschustert und treibt mit dem Artikel wieder Säue durchs verkehrte Dorf...is ja nicht das erste Mal :rolleyes:

Es stimmt, dass der Michael eine ziemlich inkompetente Persönlichkeit ist, was solche Dinge betrifft und Phoronix nicht gerade für Qualität steht. Auch wenn seine "50 Segfauls / hour" Schreibweise natürlich reißerisch ist und der conftest Fall nicht das Ryzen-Problem ist, darf man natürlich 2 Sachen nicht einfach ignorieren:

- Hardlock seines Testsystems
- Seite 2, Bild 2 (http://www.phoronix.com/image-viewer.php?id=ryzen-segv-continues&image=ryzen_segv_4_lrg) Seg-Fault in der Bash beim "hardlocked" System

Das sind sehr wohl die Ryzen-Probleme und waren sie von Anfang an. Schon bei Seite 1 dieses Threads hier. Und hier hat noch niemand gesagt: "Passiert mir auch bei $RandomAndereCPU". ;)

BlackArchon

2017-08-05, 22:01:04

Leute, denkt doch mal kurz mit kühlem Kopf nach, was gerade passiert. Wir versetzen uns mal in die Position der AMD-Manager:

Manager-Mode on:
Es liegt ein erfolgreicher Produktlaunch hinter uns. Das Desktop-Produkt wurde im März vorgestellt und kann mit den Produkten der Konkurrenz mithalten. Die öffentliche Stimmung ist unserem Ryzen-Prozessor sehr positiv gegenüber eingestellt. Ein paar kleinere technische Schwierigkeiten wie das FMA-Problem oder das VM-Problem gab es, die von unseren Technikern in kurzer Zeit gelöst wurden.
Der Server-Launch von Epyc wurde auch erfolgreich absolviert, die großen Server-Anbieter haben alle Epyc-Produkte vorgestellt. Die Kunden der Serverindustrie sind froh, endlich wieder eine Alternative zu Intel zu haben. Hier wird in Zukunft der meiste Gewinn herkommen. Gegenüber dem Desktop-Markt, wo es nur geringere Margen gibt, ist der Servermarkt für uns eine Goldgrube.
(Manager-Mode off)

Ihr könnt euch sicher sein, dass AMD alle verfügbaren internen sowie externe Ingenieure an dem Segmentation-Fault-Problem arbeiten lässt. Aktuell sind noch keine nennenswerten Zahlen von Serversystemen ausgeliefert worden, sodass noch kein nennenswerter finanzieller Schaden entstanden ist. Die ganze Industrie blickt jetzt zu AMD und beobachtet, wie effizient dort das Problem gelöst wird. Würde AMD nach acht Wochen einen Fix bringen, der das Problem scheinbar löst, und später würde es doch wieder zum Vorschein kommen, wäre ein Großteil des Vertrauens der Industrie verspielt. Deshalb wird AMD das Problem sehr, sehr sorgfältig und gründlich analysieren und mögliche Problemlösungen intensivst testen, bevor sie damit an die Öffentlichkeit gehen.

Wenn ich die Kommentare von manchen Leuten so lese, egal in welchem Forum, dann scheinen manche die Vorstellung zu haben, dass bei AMD nichts weiter passiert und die wie kopflose Hühner ohne Ziel durch die Welt irren.

Leute, kommt mal in der Realität an.

Ganon

2017-08-05, 22:13:24

Wenn ich die Kommentare von manchen Leuten so lese, egal in welchem Forum, dann scheinen manche die Vorstellung zu haben, dass bei AMD nichts weiter passiert und die wie kopflose Hühner ohne Ziel durch die Welt irren.

Auch wenn ich dir im Großen und Ganzen zustimme... aber AMD weiß von dem Problem seit April. Und die AMD-Mitarbeiter auf Reddit und/oder Phoronix wirken gerade nicht so nach "kein Ding, wir haben alles im Griff"... sie wirken schon ein bisschen "wie kopflose Hühner".

Deine Annahme, AMD steckt gerade alle verfügbaren Ressourcen in die Lösung des Problems, ist eben gerade leider nur deine Annahme. AMD würde sich imo mehr einen Gefallen tun, wenn sie sagen: "Okay, da gibt's gerade noch ein Problem was unter $Umständen noch auftreten kann, wir arbeiten dran" und ab und zu mal einen Statusbericht abgeben. Stinknormale Workloads sind ja scheinbar kein Problem.

Aber bei AMD herrscht eben gerade absolute Funkstille und das ganze Problem ist von Falschaussagen, Missdeutungen und Missverständnissen einfach nur so überschwemmt und es wird einfach nicht besser. Bisher ist die Medien-Abdeckung in dem Fall noch sehr gering, aber wenn AMD eben nicht bald mal was sagt, dann kann das sehr schnell sehr hässlich werden.

edit: Und als professioneller Kunde hätte ich auch gerne solche Infos von offizieller Stelle und nicht von irgendwelchen komischen Seiten und/oder wenn das neu angeschaffte System mir Live um die Ohren fliegt.

Daedalus

2017-08-05, 23:04:50

Bei mir läuft der gcc compile Test jetzt mehrere Stunden Problem frei. Mal gucken wie es morgen früh dann aussieht. Auch beim Arbeiten hatte ich bisher nicht ein segfault (ca. eine halbe Millionen Zeilen C99 Code), bei häufigen clean compiles.

Gorkon

2017-08-05, 23:08:43

Es stimmt, dass der Michael eine ziemlich inkompetente Persönlichkeit ist, was solche Dinge betrifft und Phoronix nicht gerade für Qualität steht. Auch wenn seine "50 Segfauls / hour" Schreibweise natürlich reißerisch ist und der conftest Fall nicht das Ryzen-Problem ist, darf man natürlich 2 Sachen nicht einfach ignorieren:

- Hardlock seines Testsystems
- Seite 2, Bild 2 (http://www.phoronix.com/image-viewer.php?id=ryzen-segv-continues&image=ryzen_segv_4_lrg) Seg-Fault in der Bash beim "hardlocked" System

Das sind sehr wohl die Ryzen-Probleme und waren sie von Anfang an. Schon bei Seite 1 dieses Threads hier. Und hier hat noch niemand gesagt: "Passiert mir auch bei $RandomAndereCPU". ;)
Das da anscheinend irgendwo was mit Ryzen, der Plattform selber, evtl. (aber unwahrscheinlich) Software oder was auch immer schief läuft steht ja außer Frage. Nur was jetzt genau wäre mal schön zu wissen...da gehe ich 100%ig D'Accord: AMD darf gerne mal was dazu kundtun ;)

Ich bleibe trotzdem dabei, dass das alles sehr fischig ist. Ja, Segfaults gabs auch unter WSL, aber afaik keine Hardlocks oder "MCEs" unter Windows oder? Da muss auch irgendwo im Kernel was nicht richtig funktionieren...

StefanV

2017-08-05, 23:14:11

Aber bei AMD herrscht eben gerade absolute Funkstille
Ja, weil sie kein Kommentar raushauen werden, bevor sie nicht genau wissen, was Sache ist bzw wie man das beheben kann.
Es wäre das dümmste, was sie tun können, wenn sie ein falsches Statement raushauen würden und sich das im Nachhinein als falsch herausstellen würde.

und das ganze Problem ist von Falschaussagen, Missdeutungen und Missverständnissen einfach nur so überschwemmt und es wird einfach nicht besser.
Ja, das übliche AMD Problem...
Das sieht man auch hier sehr schön, dass einige Leute AMD mit Gewalt schlecht reden und alles so negativ wie möglich auslegen werden.
Bei Intel gibt es dieses Problem nicht, die haben genug Leute auf ihrer Seite, die die 'Skeptiger' niederknüppeln...

Das ganze erinnert immer mehr und mehr an die Politik, die sich gerade in der US of A abspielt.
Die eher auf der Linken Seite des politischen Spektrum angeordneten, versuchen alles aus dem Weg zu räumen, z.T. gewaltsam, was nicht ihrer Meinung entspricht. Die andere Seite hingegen hat bisher alles ignoriert, was die nicht interessiert.
Gewisse Parallelen sind hier zu erkennen...

Von daher wäre es schön, wenn einige Herrschaften mal 'nen Gang zurück schalten würden und nicht so krampfhaft versuchen würden, AMD zu flamen und, wenn es sie schon nicht (mehr) tangiert, die Füße still halten würden.
Denn an der Lösung des ganzen besteht anscheinend kein Interesse...

Und wie Skysnake (und auch Exxtreme) sagten, wissen wir momentan überhaupt nicht, was denn nun genau das Problem ist. Imme rnoch nicht. Wir wissen nur, dass es auf Ryzen auftritt...

Aber was ist jetzt mit dem "Real Time Kernel"??
Davon wurde doch berichtet, dass das Abhilfe schaffen sollte?? Was ist daraus geworden??
Hat das schon mal jemand von euch ausprobiert??

Deine Annahme, AMD steckt gerade alle verfügbaren Ressourcen in die Lösung des Problems, ist eben gerade leider nur deine Annahme.
Wie komms du auf den Gedanken, dass dem nicht so ist?!
Natürlich werden sie das - im Rahmen der Möglichkeiten - machen.
Sie werden natürlich jetzt nicht die ganzen Entwickler von bestehenden Projekten abziehen - das wäre ja noch bescheuerter - aber sie werden jeden Entwickler, der auch nur irgendwie daran arbeiten kann, dafür einsetzen. Dass das nicht alle Entwickler sein werden, sollte ja wohl klar sein.
Aber das Ryzen Team sollte frei sein.

Und dass die das ganze immer noch nicht gefunden haben, deutet doch eher auf das hin, was Skysnake sagte!
Dass man nicht weiß, was die Ursache davon ist, davon sollten wir immer noch ausgehen.
Und auch wir sollten uns mit irgendwelchen Urteilen zurückhalten...

Ganon

2017-08-05, 23:15:28

Ich bleibe trotzdem dabei, dass das alles sehr fischig ist. Ja, Segfaults gabs auch unter WSL, aber afaik keine Hardlocks oder "MCEs" unter Windows oder? Da muss auch irgendwo im Kernel was nicht richtig funktionieren...

Lies dir mal das und den Text hinter den Links durch: https://svnweb.freebsd.org/base?view=revision&revision=321899

Es kommt drauf an wie der Kernel den Speicher verwaltet und wohin er ihn packt, um den entsprechenden Bug zu triggern. Wie Windows das macht, kann man ja nun nicht einfach nachschauen.

Bei Intel gibt es dieses Problem nicht, die haben genug Leute auf ihrer Seite, die die 'Skeptiger' niederknüppeln...

Was für Skeptiker die man niederknüppeln muss? Auch bei Intel waren alles harte, böse CPU Bugs die aber allesamt mehr oder weniger zeitnah gefixt wurden.

iuno

2017-08-05, 23:30:13

Ja, weil sie kein Kommentar raushauen werden, bevor sie nicht genau wissen, was Sache ist bzw wie man das beheben kann.
Es wäre das dümmste, was sie tun können, wenn sie ein falsches Statement raushauen würden und sich das im Nachhinein als falsch herausstellen würde.
Ja klar, nichts sagen ist natuerlich besser. Es sollte zumindest ein offizielles Statement geben, dass man daran arbeitet und ggf. Produkte zurueckzieht. Epyc und TR koennte man z.B. noch zurueckhalten, bis die Sache geklaert ist.

Da kauft doch nie wieder jemand was wenn man aktuell nicht sicher sein kann, ob das System zuverlaessig ist. Oder wenn man jetzt scheinbar zufriedener Kunde ist und es unvorhersehbar irgendwann mal abschmiert und man dann erfaehrt, dass das Problem laengst bekannt ist und AMD nie was dazu gesagt hat.

Ich bin sonst mit meiner CPU zufrieden, das Problem betrifft mich zwar, aber es haelt sich in Grenzen und ich sitze es jetzt erstmal aus (kann ja auch nichts anderes machen als es wegzuschmeissen) und schaue was passiert. Wenn das aber so weitergeht, haben sie mich als Kunden verloren.

Isen

2017-08-05, 23:31:26

Ganon, mit verlaub. Wieso ignorierst du z.B. meinen Umstand, dass auf dem auslieferungsbios, zum Release des C6H - also Agesa 1004 ich den kompletten 250k Loop geschafft habe, obwohl, wie weiter hinten zu sehen mit aktuelleren bzw. Agesa 1006 nichts länger als 3-4h gehalten hat...

Plattform trifft es derzeit gut.... ich bin gespannt auf das nächste Beta Bios....

Ja klar, nichts sagen ist natuerlich besser. Es sollte zumindest ein offizielles Statement geben, dass man daran arbeitet und ggf.

Wurde doch, vor 2 Monaten, im Support-Forum bei AMD selbst... - Sinngemäß: Wir untersuchen den Fall.... ab da gab es dann keine Reaktionen mehr...

Edit: Thanks for the post, I believe you opened a service request on this same issue. I will respond to your service request so we can continue the discussion there to save duplicating.
I understand, we're looking at the issue.
We're still investigating the issue, once i have an update i will post about it here.
There is no need to open new tickets on this issue. We are investigating and as soon as there is any updates, i will let you all know in this thread.

Magst noch nen Blumenstrauß dazu oder wie?

Ganon

2017-08-05, 23:42:18

Ganon, mit verlaub. Wieso ignorierst du z.B. meinen Umstand, dass auf dem auslieferungsbios, zum Release des C6H - also Agesa 1004 ich den kompletten 250k Loop geschafft habe, obwohl, wie weiter hinten zu sehen mit aktuelleren bzw. Agesa 1006 nichts länger als 3-4h gehalten hat..

Weil, wie ich schon sagte, mich mehr interessiert, ob bei dir der "Compiler-Bug" auftritt (z.B. GCC in Dauerschleife kompilieren) und nicht irgend ein Tool, was sich als unzuverlässig herausgestellt hat.

Wenn du dieses Problem mit einem älteren BIOS dort ebenso nicht nachvollziehen kannst, dann solltest du das AMD über Phoronix oder Reddit einfach mitteilen und nicht unbedingt nur mir hier im Forum.

Aber wie ich schon sagte... auch wenn es einige weiterhin ignorieren: Über die Phase des Rätselratens ist man eigentlich schon seit einer Weile hinaus. Das was AMD zur Zeit vielleicht noch interessiert ist, ob es "nicht-betroffene" Systeme gibt (siehe Meldung von Daedalus hier), oder wie vielfältig das Problem vielleicht noch ist.

Isen

2017-08-05, 23:44:17

Das tue ich doch sowieso schon.
In dem Thread hier habe ich vieles genannt, das bringt aber nichts, weswegen ich sowieso alles bereits an AMD geschickt habe... und nein, es ist nicht nur das olle Tool. Hab auch die nette Anleitung entdeckt und entsprechend getestet... keine Sorge.

Ganon

2017-08-06, 00:25:22

Hab auch die nette Anleitung entdeckt und entsprechend getestet... keine Sorge.

Na dann ist doch alles schick. :)

Ich hätte halt nämlich gerne in naher Zukunft ein Ryzen-System und würde mir wünschen, dass bis dahin diese Sachen eben vom Tisch sind. Aber da sich seit April hier quasi nichts getan hat, werde auch ich langsam ungeduldig...

Ganon

2017-08-06, 00:34:20

Hier eine Analyse zu den Crashdumps (runterscrollen zu "Postmortem Examination"):

http://fujii.github.io/2017/06/23/how-to-reproduce-the-segmentation-faluts-on-ryzen/

Isen

2017-08-06, 00:40:50

thx - ich sag es mal wie dort: It’s a Mystery! :D

StefanV

2017-08-06, 00:56:30

Ja klar, nichts sagen ist natuerlich besser.
Was soll man denn sonst machen, sofern man noch nicht weiß, was Sache ist oder wie man das löst??

Es sollte zumindest ein offizielles Statement geben, dass man daran arbeitet und ggf. Produkte zurueckzieht. Epyc und TR koennte man z.B. noch zurueckhalten, bis die Sache geklaert ist.
Damit man den Laden dann gleich zu machen kann?
Damit man den Intel Fans genug Zündstoff bieten kann??

Das ist schwierig für ein Unternehmen mit solch einem Problem...
Und du musst die Schäden, die ein solches Statement haben würde, abwegen...

Das ganze ist leider nicht ganz so einfach und schön, wie wir uns wünschen würden. Es gibt leider genug Herrschaften/Institutionen, die nur auf eine kleinste Gelegenheit warten, um AMD ans Bein pinkeln zu können...

Ich würde mir auch wünschen, wenn die Unternehmen ehrlicher und offener arbeiten würde. Aber ich muss auch einsehen, dass das leider nicht so einfach ist und gerade in der aktuellen Kultur zum Teil nicht möglich.
Das siehst du ja auch sehr schön in diesem Forum an den VEGA Threads, wie viele Leute dort ihre Schadenfreude zum Ausdruck bringen müssen...

Da kauft doch nie wieder jemand was wenn man aktuell nicht sicher sein kann, ob das System zuverlaessig ist.
Ja, genau das wären die Auswirkungen, die ein Statement, wie du es dir wünschen würdest, auslösen würde!
Dann würde das wirklich jeder mitbekommen und - wie beim Phenom I - verbrannte Erde hinterlassen.

AMD hat das in der aktuellen Situation schon nicht ganz einfach...

Oder wenn man jetzt scheinbar zufriedener Kunde ist und es unvorhersehbar irgendwann mal abschmiert und man dann erfaehrt, dass das Problem laengst bekannt ist und AMD nie was dazu gesagt hat.
Das betrifft aktuell wieviele??
Das ist doch das Problem bei dem ganzen. Es betrifft nur eine kleine Randgruppe (sorry, aber ist doch so), mit speziellen Bedürfnissen, die davon betroffen sind. Über 90% der Leute (eher sogar 95%), die Ryzen überhaupt in Betracht ziehen, interessiert da doch momentan nicht...

Natürlich ist das aktuell auch wieder eine richtig beschissene Situation, aber mit einem 'offiziellen Statement' hätte man die gleiche Situation wie damals mit den Phenomen, die dann auch wie Blei in den Regalen liegen blieben und sich jeder 'nen Core 2 gekauft hat...

Ich bin sonst mit meiner CPU zufrieden, das Problem betrifft mich zwar, aber es haelt sich in Grenzen
Genau das ist doch der Punkt...
Es ist aktuell ziemlich doof, aber so ein Drama ist das (momentan) auch nicht, da sich das ganze in Grenzen hält.
Und wenn möglich, wird man das ganze fixen wollen, ohne das ganze an die Große Glocke zu hängen...

und ich sitze es jetzt erstmal aus (kann ja auch nichts anderes machen als es wegzuschmeissen) und schaue was passiert. Wenn das aber so weitergeht, haben sie mich als Kunden verloren.
Abwarten und Tee rauchen.
Es wird gefixt werden müssen, spätestens mit EPYC (und ggF Threadripper) wird das ganze etwas wichtiger....

€dit:
Hast du mal versucht die CPU auf einen festen Takt zu forcieren??
3GHz sollten für den Anfang reichen.

gravitationsfeld

2017-08-06, 04:51:53

Ich hab ne neue CPU bekommen und die laeuft soweit stabil. Vielleicht gab es doch mal einen Bugfix?

Isen

2017-08-06, 04:56:14

RMA oder wie? Erzähl!

gravitationsfeld

2017-08-06, 05:32:48

Ne, einfach ne neue von IT auf Arbeit.

Das ist natuerlich statistisch komplett irrelevant.

Isen

2017-08-06, 05:33:43

Ah ok.

bun

2017-08-06, 05:49:15

Wieso redet ihr von einem "Ryzen Bug" wenn das Problem mit diversen anderen CPUs, darunter auch Intel, auch auftritt? :confused:

https://www.reddit.com/r/Amd/comments/6runcc/reported_epyc_segfault_might_not_be_true/dl7zweg/

Da habt ihr dann auch eure Antwort warum bei AMD keiner mit den Händen über dem Kopf im Kreis läuft und nach Gottes Hilfe schreit. :rolleyes:

aufkrawall

2017-08-06, 05:52:30

Ganons Posts lesen.

bun

2017-08-06, 06:10:10

Ich lese immer alle Posts bevor ich antworte. Ändert nichts an der Sache. Der Thread gehört ins Spekulationsforum mit neutralem Titel.

Ganon

2017-08-06, 09:39:49

Ich lese immer alle Posts bevor ich antworte. Ändert nichts an der Sache. Der Thread gehört ins Spekulationsforum mit neutralem Titel.

Nun, "Das Problem" ist nur leider nicht das von dir verlinkte, sondern bezieht sich auf die (hinter deinem Link) verlinkte Seite, die einen Seg-Fault in einem Tool für den Ryzen-Bug hielt.

Das habe ich hier (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11451086&postcount=219) auch geschrieben.

Das Thema ist weder Spekulation, noch ist der Titel falsch. Man kann maximal darüber spekulieren warum es auftritt. Leider wird eine technische Diskussion hier ja "niedergeknüppelt" ;)

Pirx

2017-08-06, 10:55:01

Was ist jetzt das genaue Problem? Etwas in Dauerschleife kompilieren mit bestimmten Compilern, oder mit egal welchem Compiler?

Ganon

2017-08-06, 11:03:58

Was ist jetzt das genaue Problem? Etwas in Dauerschleife kompilieren mit bestimmten Compilern, oder mit egal welchem Compiler?

Etwas in Dauerschleife kompilieren, egal welcher Compiler (und OS) führt entweder zu einem kompletten System Lockup oder eben zu einem Abbruch des Kompilierungs-Vorgangs.

Während der System-Lockup davon abhängig ist, wie der Kernel den Speicher an sich verwaltet (kann man quasi einen Workaround im Kernel machen), schlägt das Kompileren in Dauerschleife zumindest auf sehr sehr vielen Ryzen-Systemen fehl.

Details hatte ich weiter oben verlinkt.

Screemer

2017-08-06, 18:13:22

Und dass das eben nicht alle ryzen Systeme betrifft ist wohl auch unstrittig. Erst mal sollten die Randbedingungen abgesteckt werden bevor man sagt Zeppelin hat nen unbehebaren bug.

Pirx

2017-08-06, 20:30:41

bei ihm mit nem EPYC scheint es durchzulaufen https://www.reddit.com/r/Amd/comments/6rmq6q/epyc_7551_mining_performance/dl6puu9/

bun

2017-08-06, 22:30:43

Nun, "Das Problem" ist nur leider nicht das von dir verlinkte, sondern bezieht sich auf die (hinter deinem Link) verlinkte Seite, die einen Seg-Fault in einem Tool für den Ryzen-Bug hielt.

Das habe ich hier (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11451086&postcount=219) auch geschrieben.

Merkwürdigerweise läd das Bild nicht mehr. :D

Das Thema ist weder Spekulation, noch ist der Titel falsch.

Was haben sich aufhängende Betriebssysteme (eines einzelnen Journalisten der nicht für Kompetenz oder Seriösität bekannt ist) mit Compiler-Bugs zu tun?

Warum sind Compiler die sich auf beliebigen CPU Architekturen aufhängen Ryzen Bugs?

Man kann maximal darüber spekulieren warum es auftritt.

Dafür gibt es ja das entsprechende Forum.

Leider wird eine technische Diskussion hier ja "niedergeknüppelt" ;)

Nein. Es fehlt nur an diskutierbarer Substanz und Interpretationskompetenz.

Ganon

2017-08-06, 23:04:28

Was haben sich aufhängende Betriebssysteme (eines einzelnen Journalisten der nicht für Kompetenz oder Seriösität bekannt ist) mit Compiler-Bugs zu tun?

Nun, du könntest auch einfach mal den Thread von Anfang an lesen, dann siehst du, dass es nicht nur das OS "eines einzelnen Journalisten" ist ;)

Warum sind Compiler die sich auf beliebigen CPU Architekturen aufhängen Ryzen Bugs?

Weil die Compiler das nur auf Ryzen tun und du das gerade nur mit der "conftest"-Verwirrung von Phoronix durcheinander bringst. Auch schon seit Seite 1 dieses Threads.

Nein. Es fehlt nur an diskutierbarer Substanz und Interpretationskompetenz.

Nun, diverse Links auf den ersten Seiten des Threads und auch diverse Links u.a. von mir zwischen drin bieten durchaus einiges an technischer Tiefe was genau bei Ryzen schief läuft.

Leider kommt es darüber aber zu keiner Diskussion, weil die Leute es leider dauernd als "Nicht-Existent" abtun, oder weil wieder jemand ankommt, der behauptet es wäre doch nur ein OS oder nur ein Compiler betroffen und es somit als Software-Bug ganz woanders abtut. Ein Großteil der "Diskussion" ist hier leider auch nur eine Wiederholung der ersten 1-2 Seiten dieses Threads, weil die Leute es ebenfalls schlicht nicht nachlesen.

Aber gut. Du bist jetzt schon wieder eine Person, der man das Problem vom Urschleim an noch mal erklären muss. Ich hab dann nun im Endeffekt auch keine Luste mehr drauf, es auch noch der Person nach dir zu erklären.

Wenn noch informatives kommt, werde ich es hier teilen, aber wer meint das Problem sei nicht vorhanden, ausgedacht, eine Verschwörung oder ein einzelner Bug in einer einzelnen Software irgendwo, bitte, von mir aus... ich warte derweil auf die Antwort von AMD.

StefanV

2017-08-06, 23:21:39

Und dass das eben nicht alle ryzen Systeme betrifft ist wohl auch unstrittig. Erst mal sollten die Randbedingungen abgesteckt werden bevor man sagt Zeppelin hat nen unbehebaren bug.
Genau _DAS_ ist doch der Punkt, den einige in diesem Thread nicht verstanden haben oder verstehen wollen.
Insbesondere die ganzen Beiträge von Skysnake sind hier am hilfreichsten, was dieses Thema betrifft.

Und ich möchte dazu auch nichts weiter sagen, eben weil ich nichts weiter weiß.
Aber das, was Skysnake dazu sagte, klingt mehr als einleuchtend...

Jetzt muss AMD nur den Fehler finden...
Das Problem ist, wie sie es aus der Welt schaffen. Ich hoffe mal, dass es ein Software Update gibt oder aber dass es einen stillen Austausch gibt.

aufkrawall

2017-08-06, 23:36:01

Vielleicht nochmal Beitrag #1 lesen?

bun

2017-08-07, 03:16:34

Nun, du könntest auch einfach mal den Thread von Anfang an lesen, dann siehst du, dass es nicht nur das OS "eines einzelnen Journalisten" ist ;)

Ich habe einen einzelnen Bericht über OS Hänger im Gentoo Thread gefunden. 71 Ryzen Besitzer beschäftigen sich mit dem Bug, und bei einem hängt mal das OS? Nicht sehr aussagekräftig.

Weil die Compiler das nur auf Ryzen tun und du das gerade nur mit der "conftest"-Verwirrung von Phoronix durcheinander bringst. Auch schon seit Seite 1 dieses Threads.

Das stimmt nicht. Selbst im Gentoo Thread erwähnt Jemand mindestens einen core 2 duo der das Problem auch hat.

Nun, diverse Links auf den ersten Seiten des Threads und auch diverse Links u.a. von mir zwischen drin bieten durchaus einiges an technischer Tiefe was genau bei Ryzen schief läuft.

Theorien, Vermutungen, "Lösungen" die nicht immer helfen. Man weiß immer noch nicht was schief läuft, und ob das jetzt ein Ryzen Bug ist, oder ein korrekt funktionierendes Ryzen Feature das Software Bugs öfter vorkommen lässt, weiß man nicht. Das als Ryzen Bug darzustellen ist keine neutrale Darstellung.

Leider kommt es darüber aber zu keiner Diskussion, weil die Leute es leider dauernd als "Nicht-Existent" abtun, oder weil wieder jemand ankommt, der behauptet es wäre doch nur ein OS oder nur ein Compiler betroffen und es somit als Software-Bug ganz woanders abtut. Ein Großteil der "Diskussion" ist hier leider auch nur eine Wiederholung der ersten 1-2 Seiten dieses Threads, weil die Leute es ebenfalls schlicht nicht nachlesen.

Ich habe nie behauptet, das das Problem nicht existiert, oder nur mit bestimmter Software X auftritt. Ich finde es nur nicht in Ordnung, das als AMD/Ryzen Problem darzustellen, wenn die Ursache noch völlig unbekannt ist. Du siehst ja welche Blüten das gleich wieder treibt und in welche Ecke AMD gestellt wird bevor man überhaupt weiß was los ist.

Aber gut. Du bist jetzt schon wieder eine Person, der man das Problem vom Urschleim an noch mal erklären muss.

Ich habe das schon verstanden, und auch gelesen. Ich habe nur eine völlig andere Ansicht.

Aus dem ersten Post in diesem Thread:

https://forums.gentoo.org/viewtopic-t-1061546-postdays-0-postorder-asc-start-200.html?sid=4f8fc551a0b764a6ecb3d9cb7f19e028

https://forums.gentoo.org/viewtopic-p-8091972.html#8091972

EDIT: I don't know what to think anymore. The ryzen_segv_test ran for a few hours without any errors under Windows. Having read that gcc 6.4 is out and some people reported stable compilation with Ryzen using it, I thought I would test it out in Gentoo. I compiled gcc 6.4 from source and used that to compile the ryzen_segv_test. It ran without segfault for a few hours, so I thought this might be a solution. I let it run overnight, however, and it did segfault once (out of approx 350K "OK" results). So now I'm going to have to try the windows version for much longer to see if it crashes on a long run. Oddly enough, I went back to trying the ryzen_segv_test compiled with gcc 7.1 and it ran for over 2 hours without a segfault as opposed to the 5-10 minutes I experienced earlier.

https://forums.gentoo.org/viewtopic-p-8093178.html#8093178

I had them also on core 2 duo, then I used older compiler and everything was ok.
(I used march znver1 )

So how is that all ryzen fault, not eg bad flags or gcc bug ?

https://forums.gentoo.org/viewtopic-p-8073310.html#8073310

I have exported the present info to a spreadsheet so people can see.( https://docs.google.com/spreadsheets/d/1gzniXYcXm1uACXGoBLpbpq54KE6SlHxQ6M_wPnTkub8/edit?usp=sharing)

20x No
51x Yes

https://forums.gentoo.org/viewtopic-p-8069978.html#8069978

my system is working fine

If you are using a kernel < 4.10 you will have potential issues
If you are using gcc < 5.x you will have potential issues (6.3 starts being good, 7.1 is nice)
If you are not using the latest BIOS you will have potential issues
If your BIOS has set the wrong RAM info (voltage & timing) you will have issues

In dem Thread gibt es noch ganz andere Perlen:

https://forums.gentoo.org/viewtopic-p-8057818.html#8057818

NeddySeagoon, you are a genius !
I had 3 versions of binutils for the same architecture on my system. Guess what happened:
The newest one got always rebuild, but the oldest one was used.
I cleaned this mess up and I am compiling like crazy the whole day for testing. No segfaults so far on both systems.

https://forums.gentoo.org/viewtopic-p-8061814.html#8061814

I didn't have the test equipment to make measurements to confirm that but replacing all the capacitors in the motherboard regulator fixed the problem.

https://forums.gentoo.org/viewtopic-p-8075578.html#8075578

https://community.amd.com/message/2796982

Disabling both uOP cache and SMT does nothing for me.
Disabling ASLR seems effective for me.

ASLR? ASLR: https://de.wikipedia.org/wiki/Address_Space_Layout_Randomization

Address Space Layout Randomization (ASLR; deutsch etwa Zufallsgestaltung des Adressraum-Aufbaus, kurz Speicherverwürfelung oder Adressverwürfelung genannt) ist eine Technik, die die Ausnutzung von Sicherheitslücken in Computersystemen erschwert. Durch ASLR werden Adressbereiche den Programmen auf zufälliger Basis zugewiesen, wodurch die Zuweisung der Adressbereiche eines Programms praktisch nicht mehr vorhersagbar ist. Dies soll Angriffe durch Pufferüberlauf erschweren.

https://forums.gentoo.org/viewtopic-p-8076910.html#8076910

I can confirm that turning off ASLR completely eliminates any random segmentation faults during compilation.

Die diversen "ich hab einen Ryzen Bug" Posts die dann Jemand mit "Ist ein bekannter Bug in Software X" entkräftet könnt ihr selbst suchen.

Man kann sich auch einen Spaß daraus machen die Posts zu zählen in denen Overclocking oder 3000Mhz+ RAM auftauchen.

Niemand versucht Etwas wegzureden, man sollte das im Auge behalten, aber wenn man sich seriös verhält kann man eigentlich nur Abwarten und Beobachten. Schuldzuweisungen in jedwede Richtung sind verfrüht, genau das passiert aber schon im Thread Titel.