AMD - Ryzen "Compiler-Bug" [Archiv] - Seite 2

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

Daedalus

2017-08-07, 16:30:49

So 16h Stunden am Stück gcc kompilieren ohne Probleme. Meine Probleme waren scheinbar nur auf RAM Takt und Timings zurück zu führen.

aufkrawall

2017-08-07, 19:18:44

Kann sein, dass die BSD-Problematik noch wieder eine andere ist.
Es bringt aber nichts, in Hyperaktionismus lauter Zitate rauszukramen, die alles mögliche aussagen, weil jeder Hans im Web irgendwas erzählt.
Wir müssen auch gar nicht so weit schauen, iuno hat mit Stock-Werten schon genau das gleiche Problem nachgestellt, das ich hatte. Und nochmal: Mit Clang ist es wohl wesentlich einfacher zu provozieren als mit GCC.
Clang segfaulted auf Intel und älteren AMDs nicht, und bei Phoronix-Michael (der btw. den reißerischen Titel der News abgeändert und ein Update gepostet hat) ist das Ryzen-System ausgerechnet bei Clang komplett abgeschmiert. Mal sehen, was er demnächst postet.

StefanV

2017-08-07, 19:31:54

Und dennoch müssen wir nicht krampfhaft auf AMD rumkloppen, da wir nun wirklich NICHT wissen, was denn nun Sache ist.

Und die Zitate von bun und auch die Aussage von gravitationsfeld belegen eindeutig, dass es kein generelles Problem am Chipdesign ist sondern eher in Richtung Fertigung zu sein scheint.

Und zum Teil sind es auch Probleme/Bugs in der Software.

Ganon

2017-08-07, 20:20:17

AMD hat das Problem im Prozessor gegenüber Phoronix am Telefon bestätigt:

http://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response

Der Marketing Mensch am Telefon nennt es "performance marginality" ( :ugly: ) und betroffene Kunden mögen sich bitte bei AMD Customer Care melden. Die Tests sind bei AMD aber noch nicht abgeschlossen.

Epyc und ThreadRipper sollen aber laut ihm nicht betroffen sein.

Ätznatron

2017-08-07, 21:45:21

AMD's testing of this issue under Windows hasn't uncovered problematic behavior.

Zumindest tritt es nicht mit Windows auf. An Microsofts Software liegt es also nicht.

AMD engineers found the problem to be very complex and characterize it as a performance marginality problem exclusive to certain workloads on Linux.

Mit Linux hingegen, tja...

Screemer

2017-08-07, 21:50:26

Es wird hier und anderswo von lauter zweifelhaft argumentierenden Personen ständig eingeworfen, es könne ja auch an der Software liegen.
Das zieht hoffentlich erstmal einen Schlussstrich unter den Unfug.

Und andere zweifelhaft argumentierende Personen schließen das kategorisch aus. Agesa und andere firmwares sind auch software. warum tritt es scheinbar unter Windows nicht auf? Warum muss es somit ein hw Problem sein? Es gibt noch viel zu viele ungeklärte fragen um einen bug in Zeppelin als gesichert zu bezeichnen. Das hab ich jetzt schon mehrfach hier geschrieben aber horen will das von euch naysayern ja eh keiner.

aufkrawall

2017-08-07, 22:03:20

Abwarten, ob es unter Windows wirklich nicht auftritt. Und das Thema "warum nur Linux" kann man mit etwas Geistesaktivität genau so für den letzten Intel HTT-Bug fragen (hatte ich hier auch schon eingeworfen..).

Pirx

2017-08-07, 22:04:47

Es wird hier und anderswo von lauter zweifelhaft argumentierenden Personen ständig eingeworfen, es könne ja auch an der Software liegen.
---
Der "Unfug" fing mit dem ersten Post (deinem) dieses Threads an, in dem du richtig ekligen FUD gepostet hast. Bis jetzt hast du dich nicht zu einer konstruktiven Betrachtungsweise entschließen können, greifst aber andere an, die sich deiner Ausschließeritis nicht anschließen wollen.

Ganon

2017-08-07, 22:15:45

Also OK, wir ignorieren jetzt einfach mal, dass man das Problem auch unter allen anderen Betriebssystemen (inklusive dem Linux Subsystem für Windows) auftritt und der Marketing-Typ sich nur auf Linux gestützt hat, weil ihm vermutlich nicht mehr Infos vorlagen:

-> AMD sagt, dass (frühe) Ryzen Prozessoren betroffen sind
-> AMD sagt, dass Epyc und ThreadRipper nicht betroffen sind
-> AMD sagt, dass das Problem unabhängig vom Mainboard ist
-> AMD sagt, dass die betroffenen Kunden sich an den Customer Care wenden sollen
-> AMD sagt, sie wollen in Zukunft die Linux QA aufstocken

Ihr könnt jetzt natürlich weiterhin ein Software-Problem in Linux vermuten, ich würde an der Stelle aber allen Betroffenen einfach empfehlen, das zu tun was AMD sagt: AMDs Kundensupport / den Händler kontaktieren und somit vermutlich eine neue CPU kriegen.

aufkrawall

2017-08-07, 22:16:03

Der "Unfug" fing mit dem ersten Post (deinem) dieses Threads an, in dem du richtig ekligen FUD gepostet hast. Bis jetzt hast du dich nicht zu einer konstruktiven Betrachtungsweise entschließen können, greifst aber andere an, die sich deiner Ausschließeritis nicht anschließen wollen.
Komisch, dass der "richtig eklige FUD" hier erst vor Kurzem richtig neue Nahrung erhalten hat:
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11451299#post11451299

Und so lange mir keine segfaults bei Clang mit anderen stabil betriebenen CPUs von AMD & Intel bekannt sind, sind mir andere Meinungen auch wirklich herzlich egal.
Erst recht, wenn weiter auf Stuss-Basis wie den Test-Tools argumentiert wird, die hier von mehreren des Programmierens fähigen Menschen mit guter Linux-Kenntnis schon auf mehreren Seiten als wertlos eingestuft wurden.

Pirx

2017-08-07, 22:22:48

Komisch, dass der "richtig eklige FUD" hier erst vor Kurzem richtig neue Nahrung erhalten hat:...
Mag ja sein, daß es stimmt. Solange du es aber nicht beweisen kannst bzw. alle anderen Möglichkeiten ausschließen kannst ist deine Aussage nicht seriös.
Wieso gehst du bei diesem Thema aber trotzdem den Weg der Vorverurteilung?

aufkrawall

2017-08-07, 22:29:55

Ich hatte schon längst ausführlich deutlich gemacht, dass es Spekulation war. Möglichkeitsform ist dir ein Begriff?
Dass mehr und mehr darauf hindeutet, dass es zutrifft, well...

Btw: Beim 970 VRAM-Beschiss hab ich mich auch übers ganze Gerede hinweggesetzt und sollte Recht behalten, falls ihr meint, ich würd bei AMD irgendwie andere Standards anlegen...
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=10481988#post10481988

Unicous

2017-08-07, 22:32:14

Sorry, aufkrawall.

Du unterliegst hier gerade einem fetten confirmation bias und ignorierst gekonnt, dass es noch keine konkreten Beweise für einen Hardware Bug gibt, bzw. dieser nicht durch ein hypothetisches Microcode Update gefixed werden könnte oder es nicht doch ein Kernel-Bug ist.

Es gibt mehr Fragezeichen als Ausrufezeichen und dabei sollte man es erst einmal belassen.

Und ja, man darf Michael gerne und oft auf die Finger hauen, weil er sich ständig solch einen Müll erlaubt und den dann nicht einmal korrigiert. Er erliegt nämlich dem selben confirmation bias und dem Drang eine Schlagzeile zu erzeugen. Im Forum gibt er sich dann immer kleinlaut wenn ihm das vorgehalten wird. Den Bullshit-Artikel hat er übrigens auch nicht geupdatet oder zurückgezogen... oh wait er hat ihn geupdatet, mit einem Link zu dem neuen Artikel in dem "AMD" zugibt es gäbe eine "performance marginality". Morgen kommt zu dem Thema dann der nächste Artikel oder auch zwei. Und dann am nächsten könnte ich drauf wetten kommt noch einer. :rolleyes:

Und du kannst mir auch gerne erklären wie ein Chip der im gleichen Stepping vom Band läuft einen Bugfix enthalten könnte, wenn der Microcode derselbe ist (der wird übers AGESA eingespielt, bzw. wüsste ich von keiner anderen Methode).

aufkrawall

2017-08-07, 22:40:32

Sorry, aufkrawall.

Du unterliegst hier gerade einem fetten confirmation bias und ignorierst gekonnt, dass es noch keine konkreten Beweise für einen Hardware Bug gibt

Wo verläuft die Grenze zwischen Beweis und deutlichem Indikator?

, bzw. dieser nicht durch ein hypothetisches Microcode Update gefixed werden könnte oder es nicht doch ein Kernel-Bug ist.

Ich habe überhaupt nicht ausgeschlossen, dass es über den Microcode gefixt werden könnte.
Kernel-Bug kann man aber offenbar ausschließen, weil es afaik auch mit dem Linux Subsystem für Windows beim echten Kompilieren (also nicht nur bei den künstlichen Test-Tools) auftritt.
(Hat Ganon auch jüngst wieder erwähnt. Ihr seid einfach unfähig, genau zu lesen und die Informationen mitzunehmen...).

Es gibt mehr Fragezeichen als Ausrufezeichen und dabei sollte man es erst einmal belassen.

Clang crasht nur auf Ryzen, nix Fragezeichen.

Und ja, man darf Michael gerne und oft auf die Finger hauen, weil er sich ständig solch einen Müll erlaubt und den dann nicht einmal korrigiert.

Ich habe bereits erwähnt, dass er sich korrigiert hat.
Lesen...

Im Forum gibt er sich dann immer kleinlaut wenn ihm das vorgehalten wird.

Es reicht, wenn er den Artikel updatet.

Den Bullshit-Artikel hat er übrigens auch nicht geupdatet oder zurückgezogen... oh wait er hat ihn geupdatet, mit einem Link zu dem neuen Artikel in dem "AMD" zugibt es gäbe eine "performance marginality".

Schon wieder Leseschwäche.
Er hat in den ursprünglichen Artikel einen Update-Absatz eingefügt und die reißerische Überschrift mit den "XXX segfaults per hour" abgeändert.

Morgen kommt zu dem Thema dann der nächste Artikel oder auch zwei. Und dann am nächsten könnte ich drauf wetten kommt noch einer. :rolleyes:

Dann lies es halt nicht, wenn du nicht fähig bist, Informationen von reißerischem Bla zu trennen.

Und du kannst mir auch gerne erklären wie ein Chip der im gleichen Stepping vom Band läuft ein Bugfix enthalten könnte, wenn der Microcode derselbe ist (der wird übers AGESA eingespielt, bzw. wüsste ich von keiner anderen Methode).
gravitationsfeld hält es für möglich.

Unicous

2017-08-07, 22:41:37

Posts zerpflücken ist zum Kotzen und unter meiner und auch deiner Würde.:rolleyes:

aufkrawall

2017-08-07, 22:43:51

Ich finds übersichtlicher. Würde ist mir egal, Fakten sind wichtiger.

bun

2017-08-08, 03:15:14

Es bringt aber nichts, in Hyperaktionismus lauter Zitate rauszukramen, die alles mögliche aussagen, weil jeder Hans im Web irgendwas erzählt.

Wenn mir unterstellt wird das ich doof bin und nichts gelesen habe, dann krame ich Zitate raus. Das hat nichts mit Hyperaktionismus zu tun sondern Konsequenz.

Der Marketing Mensch am Telefon nennt es "performance marginality" ( :ugly: ) und betroffene Kunden mögen sich bitte bei AMD Customer Care melden. Die Tests sind bei AMD aber noch nicht abgeschlossen.

Epyc und ThreadRipper sollen aber laut ihm nicht betroffen sein.

Klingt für mich als könnte es eine Kombination aus qualitativ etwas schlechteren Chips aus der frühen Fertigung und zu aggressivem Binning sein. Zu viel Takt / zu wenig Spannung, zu aggressiv gesetzte Latenzen, etc.

Es wird hier und anderswo von lauter zweifelhaft argumentierenden Personen ständig eingeworfen, es könne ja auch an der Software liegen.

Was aufgrund der kursierenden "Tests" die auf diversen Intel Chips auch Fehler werden kein absurder Ansatz war.

Posts zerpflücken ist zum Kotzen und unter meiner und auch deiner Würde.:rolleyes:

Heißt das du hast keine Gegenargumente? Wie soll man sonst sachlich diskutieren statt Argument für Argument? Himmel.

Es fällt schwer auf solche Posts zu antworten wenn ihr euch ständig selbst widersprecht und simple Logik ignoriert.

Ganon

2017-08-08, 09:43:03

Wenn mir unterstellt wird das ich doof bin und nichts gelesen habe

Doof nicht, aber "nicht gelesen haben" schon ;) Denn wie schon gesagt wurde ist und war das ursprüngliche Problem, dass Compiler-Jobs nur auf Ryzen ihren Dienst einstellen. Und auch nachdem es zig mal hier erklärt wurde, dass das so ist, kamst auch du wieder an und sagst, das Problem sei auch auf Intel nachvollziehbar. Also verzeihe mir bitte, dass ich dir das dann einfach unterstelle. ;)

Und nimm es mir nicht übel. Es ist schon durchaus schwer den Überblick zu behalten, wenn jede Diskussion / Faktenfindung hier (und auch sonst überall) von diversen Leuten mit irgendwelchen immer gleichen (bereits widerlegten) Vermutungen unterbrochen wird. So geht eben auch ein Link unter der das ganze Problem bereits technisch und auf Low-Level Ebene analysiert hat eben immer unter.

Klingt für mich als könnte es eine Kombination aus qualitativ etwas schlechteren Chips aus der frühen Fertigung und zu aggressivem Binning sein. Zu viel Takt / zu wenig Spannung, zu aggressiv gesetzte Latenzen, etc.

Durchaus möglich. Scheinbar ( bedenke: Ich habe nicht Fakt gesagt) bietet AMD bei Meldung beim Customer Care wirklich Austausch-CPUs an.

Was aufgrund der kursierenden "Tests" die auf diversen Intel Chips auch Fehler werden kein absurder Ansatz war.

Der ursprüngliche Test war aber weiterhin Zeug in Dauerschleife zu kompilieren. Der Test, der letztendlich auch auf Intel nicht durchgängig funktioniert, war ein Versuch das Problem einzugrenzen. Der kam nachträglich.

Es fällt schwer auf solche Posts zu antworten wenn ihr euch ständig selbst widersprecht und simple Logik ignoriert.

Nun, sieh es mal an dem Punkt von meinem Standpunkt aus:

- DragonFly BSD Entwickler findet Ursache für Hardlock in der CPU, kann deterministischen Test dafür entwickeln, schickt ihn an AMD
- unabhängig von einander erfahren FreeBSD und Linux Entwickler (z.B. auch die von OCaml) und Nutzer sowohl mit GCC als auch Clang random Seg-Faults beim Compilieren von Software, teilweise komplette hardlocks des Systems, häufiger bei FreeBSD, selten bei Linux
- FreeBSD / DragonFlyBSD Entwickler finden Workaround für Hardlocks des Systems durch ein "Fehlverhalten in der CPU", wenn man sich an Grenzbereichen von Speicherbereichen bewegt (eben unter Last)
- FreeBSD Entwickler entwickeln einen speziellen Test der das Problem durchaus schnell aufzeigt (Code-Ausführung ab einer bestimmten Speicheradresse -> CPU bleibt stehen)
- einige Leute machen eine Crash-Dump Analyse und finden heraus, dass die CPU, trotz korrekter Werte in den Registern, sich in der nächsten Instruktion einfach "verspringt"
. alle Aussagen wie "OpCache deaktivieren", "ASLR deaktivieren", "XZY tun" wurden von diversen Leuten als "hilft nicht" gekennzeichnet

Nebenbei kommen andere Tools und Tests hervor, die entweder falsch interpretiert wurden oder eben doch nicht das Problem eingegrenzt haben.

So... und mit dieser "Faktenlage" begegnen dir jetzt immer wieder Leute die sagen: "Das kann auch ein Bug in Linux sein", "Das kann auch ein Bug in GCC sein", "das Problem tritt auch unter Intel auf".

Im gesamten Verlauf der Diskussion wurde eben immer wieder und wiederholt das Ursprungsproblem schlicht ignoriert oder vergessen.

Dino-Fossil

2017-08-08, 14:39:26

Bei Gelegenheit werd ich mal testen ob ich betroffen bin, oder nicht, aber für's erste warte ich ab, ob es möglicherweise per microcode/BIOS-Update gefixt wird.

Immerhin schön zu sehen, dass AMD es reproduzieren kann und damit hoffentlich ein Fix möglich wird. Alternativ eben Support und neue CPU?

Kriton

2017-08-08, 16:23:40

Doof nicht, aber "nicht gelesen haben" schon ;) Denn wie schon gesagt wurde ist und war das ursprüngliche Problem, dass Compiler-Jobs nur auf Ryzen ihren Dienst einstellen. Und auch nachdem es zig mal hier erklärt wurde, dass das so ist, kamst auch du wieder an und sagst, das Problem sei auch auf Intel nachvollziehbar. Also verzeihe mir bitte, dass ich dir das dann einfach unterstelle. ;)

Und nimm es mir nicht übel. Es ist schon durchaus schwer den Überblick zu behalten, wenn jede Diskussion / Faktenfindung hier (und auch sonst überall) von diversen Leuten mit irgendwelchen immer gleichen (bereits widerlegten) Vermutungen unterbrochen wird. So geht eben auch ein Link unter der das ganze Problem bereits technisch und auf Low-Level Ebene analysiert hat eben immer unter.

Auch wenn ich damit in die von Dir kritisierte Kerbe schlage: Gilt es, dass das Problem garantiert nur bei Ryzen auftaucht auch außerhalb von Clang? Möglicherweise sind es dann ja unterschiedliche Ursachen (mit demselben Fehlerbild), wobei (sofern Clang ein Sondernfall wäre) insoweit tatsächlich ein SW-Bug vorliegen könnte.

Ich komme nur darauf, weil in meiner Wahrnehmung in dem Thread Clang immer so hervorgehoben wird, gleichzeitig aber immer wieder auftaucht, dass eigentlich (fast) alle Compiler betroffen wären. Das ist aber IMHO auch ein wenig unsystematisch in der Diskussion.

TGKlaus

2017-08-08, 16:24:39

und mit dieser "Faktenlage"

Ich erinnere da mal an ein Post von dir:

Ein Bug der unter Linux, FreeBSD, NetBSD, DragonFly BSD, Windows, GCC, Clang, dem Microsoft Compiler und generell überall auftritt

Der MS Compiler wird bei uns bei M&E im großen Maße eingesetzt. Aktuelle z.B. bei der (Treiber- und) Steuerungsprogrammierung es Handlingsystems einer kompletten Werkshalle. Wenn es da seit Ryzeneinführung im m&e Bereich vor ca. 2 Monaten zu irgendwelchen neuen / unerklärlichen Problemen gekommen wäre, wäre hier der Teufel los.

generell überall ist ne Bullshitaussage und reines AMD Bashing.

Zu den anderen Sachen kann ich nix sagen. Aber warum sollen da deine Aussagen stimmen, wenn sie in den Bereichen mit denen ich zu tun haben nicht stimmen?

ergo du bist einfach unglaubwürdig, genau wie "aufkrawall"

Das es anscheinend in gewissen Bereichen Unstimmigkeiten gibt, davon ist auszugehen. Wo genau das Problem liegt ist aber bis dato absolut unklar.

Wer behauptet das Problem zu kennen soll doch bitte ganz klar aufzeigen was los ist und kann damit bei AMD bestimmt gut Geld als "Prämie" bekommen.

Alle anderen sollten mal nen Schritt zurücktreten.

Ganon

2017-08-08, 16:36:11

Auch wenn ich damit in die von Dir kritisierte Kerbe schlage: Gilt es, dass das Problem garantiert nur bei Ryzen auftaucht auch außerhalb von Clang? Möglicherweise sind es dann ja unterschiedliche Ursachen (mit demselben Fehlerbild), wobei (sofern Clang ein Sondernfall wäre) insoweit tatsächlich ein SW-Bug vorliegen könnte.

Wie ich hier (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11451241&postcount=231) schon verlinkt habe, hat sich jemand den Crash angesehen.

Wenn das ein Software-Bug wäre, dann würden dort irgendwelche Werte bzw. Adressen im Speicher nicht stimmen. Die stimmen aber und der Prozessor springt anschließend ganz woanders hin.

generell überall ist ne Bullshitaussage und reines AMD Bashing.

Zu den anderen Sachen kann ich nix sagen. Aber warum sollen da deine Aussagen stimmen, wenn sie in den Bereichen mit denen ich zu tun haben nicht stimmen?

ergo du bist einfach unglaubwürdig, genau wie "aufkrawall"

Warum sollte ich dir glauben, wenn du mir schlicht nur AMD bashing unterstellst? ;)

Nebenbei sind das alles nicht direkt "meine" Aussagen. Ich habe so ziemlich immer auf die verlinkten Aussagen von Kernel- und Softwareentwicklern bezogen die das Problem tatsächlich untersucht haben und auch zu handfesten Ergebnissen gekommen sind.

Du kannst denen natürlich auch AMD bashing unterstellen. Du kannst auch AMD AMD-bashing unterstellen, da sie ja mittlerweile gesagt haben, dass was in der CPU nicht in Ordnung ist.

Ob jede Ryzen-CPU betroffen war oder nur die frühen Modelle war ja letztendlich seit Post #1 hier die Frage. Dass du da "AMD hat einen unbehebbaren Bug, alle Ryzen unbrauchbar, Ryzen ist Mist, kauft alle Intel" reininterpretierst ist ja nicht mein Problem.

TGKlaus

2017-08-08, 16:48:23

Nebenbei sind das alles nicht direkt "meine" Aussagen.

Genau das hab ich doch als Problem beschrieben, die Leute behaupten etwas was sie selbst nicht beweisen können und nur vom Hörensagen kennen.

Mir stellt sich da immer die Frage, warum diese Leute dann immer den Mund aufmachen und auf "dicke" Hose machen.

Dass du da "AMD hat einen unbehebbaren Bug, alle Ryzen unbrauchbar, Ryzen ist Mist, kauft alle Intel" reininterpretierst ist ja nicht mein Problem.

Das waren aber genau deine Worte. Hatte deshalb deinen Post auch zitiert:

Ryzen hat einen Bug der generell überall auftritt.
Hatte das sogar extra dick schwarz markiert. :rolleyes:

Und den letzte Teil meines Posts hast du mal gekonnt ignoriert, ehrlich gesagt hätte mich was anderes auch gewundert ...

Edit:

Wie ich hier schon verlinkt habe, hat sich jemand den Crash angesehen.

Wenn das ein Software-Bug wäre, dann würden dort irgendwelche Werte bzw. Adressen im Speicher nicht stimmen.

Hab mir das mal angesehen.
Deine Aussage dazu ist falsch.
Da die Werte stimmen, ist nicht die Frage ob die Werte stimmen oder nicht, sondern warum die Werte stimmen und trotzdem eine Schutzverletzung ausgelöst wird.

Und die Erlärung:
It’s a Mystery!

Und da sind wir genau wieder bei dem was ich gesagt habe.

Aktuelle gilt: Nichts Genaues weiß man nicht!

Skysnake

2017-08-08, 16:53:20

Die Unterstellungen kann man sich sparen, das bringt nichts.

Es gibt aber auch kein verlässliches Anzeichen für ein generelles Logikproblem in Ryzen. Wenn sieht das eher nach einem fehlerhaften Binning bzw Verifikation bzw in der dynamischen Taktänderung aus.

Das ist zwar unschön und sollte nicht passieren, kommt aber immer wieder vor. So lange das eine überschaubare Anzahl an ausgelieferten CPUs betrifft ist das kein echtes Problem.

Und bisher gibt es noch keine Anzeichen für etwas anderes.

Menace

2017-08-08, 16:57:32

Ich lese nur sporadisch mit, aber kann z.B. Ganon mal nennen, mit welchem CPUs (egal welcher Marke) bei welchen Compilern Fehlern aufgetreten sind? Mit Quellenlage? Vielleicht könnte man das ganze Versachlichen und Ganon scheint es ja wichtig zu sein und das Problem lösen zu wollen, oder?

Und das als ersten Beitrag am Anfang des Threads und aktuell halten. Bitte nur nachweisliche Fehler; nicht von Hörensagen. Laut Hörensagen heilt auch Homöopathie Krebs.

Ganon

2017-08-08, 17:17:04

Genau das hab ich doch als Problem beschrieben, die Leute behaupten etwas was sie selbst nicht beweisen können und nur vom Hörensagen kennen.

Mir stellt sich da immer die Frage, warum diese Leute dann immer den Mund aufmachen und auf "dicke" Hose machen.

Langjährige Kernel-Entwickler, die mir das Problem auf technischer Ebene erklären können, genießen bei mir ein recht hohes Ansehen. Denen glaube ich mehr als einem zufälligen Mitglied in einem Forum, der allesamt als AMD-Basher beschimpft ;)

Das waren aber genau deine Worte. Hatte deshalb deinen Post auch zitiert:

Ryzen hat einen Bug der generell überall auftritt.
Hatte das sogar extra dick schwarz markiert. :rolleyes:

Das kannst du natürlich so interpretieren. Gemeint war aber damals das OS und der Compiler.

Und den letzte Teil meines Posts hast du mal gekonnt ignoriert, ehrlich gesagt hätte mich was anderes auch gewundert ...

Wie das so ist mit Wahrscheinlichkeiten. Entweder ihr habt heile CPUs oder ihr triggert das Problem nicht. Bis vor AMDs Aussage, dass nur ein Teil der CPUs betroffen sind, war das eben unsicher.

Und da sind wir genau wieder bei dem was ich gesagt habe.

Na wenn du meinst genau das da raus zu lesen...

Es gibt aber auch kein verlässliches Anzeichen für ein generelles Logikproblem in Ryzen. Wenn sieht das eher nach einem fehlerhaften Binning bzw Verifikation bzw in der dynamischen Taktänderung aus.

Nachdem AMD sich endlich mal zu dem Thema geäußert hat kann man natürlich diverse Spekulationen einstellen. Die Frage ob nun alle betroffen sind oder nur einige. Dieses "Ryzen unbrauchbar, unfixbar, alles scheiße, AMD ist unfähig" interpretieren andere hier rein.

Ich lese nur sporadisch mit, aber kann z.B. Ganon mal nennen, mit welchem CPUs (egal welcher Marke) bei welchen Compilern Fehlern aufgetreten sind? Mit Quellenlage? Vielleicht könnte man das ganze Versachlichen und Ganon scheint es ja wichtig zu sein und das Problem lösen zu wollen, oder?

Und das als ersten Beitrag am Anfang des Threads und aktuell halten. Bitte nur nachweisliche Fehler; nicht von Hörensagen. Laut Hörensagen heilt auch Homöopathie Krebs.

Scrolle einfach etwas hoch und lies AMDs Aussage dazu. Wir brauchen eigentlich nicht mehr großartig spekulieren. AMD sagt, alle Betroffenen mögen sich beim AMD Customer Care melden. Der bietet an, soweit ich das bisher sehen konnte, die CPU auszutauschen.

Es ist glaube ich jetzt unnötig noch mal sämtliche Aussagen auf allen Kernel-Mailing-Listen und Bug-Reports durchzugehen, wenn AMD sich schon dazu gemeldet hat. Wie schon gesagt, das Compiler-Crash Problem war Ryzen-Only. Nur etwaige andere nachträgliche Test-Tools triggerten auch bei Intel.

TGKlaus

2017-08-08, 17:27:13

AMD sagt, alle betroffenen mögen sich beim AMD Customer Care melden. Der bietet an, soweit ich das bisher sehen konnte, die CPU auszutauschen.

Ganz ehrlich, LASS ES!!!

Diese Aussage stammt nicht von AMD sondern, Michael Larabel behauptet AMD hat gesagt ....

Edit:
Langjährige Kernel-Entwickler, die mir das Problem auf technischer Ebene erklären können,

Dann erkläre uns Unwissenden doch das Problem, dann wären ja alle Zweifel beseitigt.
Komisch das das bisher noch keiner getan hat.

Menace

2017-08-08, 17:34:15

Wie schon gesagt, das Compiler-Crash Problem war Ryzen-Only. Nur etwaige andere nachträgliche Test-Tools triggerten auch bei Intel.

Also sehe ich das richtig: Bei einigen frühen Ryzen gab es bei einem Compiler crashes. Bei neueren Ryzen ist das nicht mehr der Fall? Und die, die nicht funktionierten (einzelne CPUs) werden auch noch ausgetauscht? :confused:

Dino-Fossil

2017-08-08, 17:40:37

Hier übrigens noch ein Statement vom AMD Support dazu:

We have been working closely with a small but important subset of Linux users that have experienced segment faults when running heavy or looping compilations on their Ryzen CPU-based systems. The results of our testing and analysis indicate that segment faults can be caused by memory allocation, system configurations, thermal environments, and system marginality when running looping or heavy Linux compile workloads. The marginality is stimulated with very heavy workloads and when the system environment is not ideal. AMD is working with individual users to diagnose the issues.

We are confident that we can help each of you identify the source of the marginality and eliminate the segment faults. We encourage all of our Linux users who are experiencing segment faults under compile workloads to continue working with AMD Customer Care. We are committed to solving this issue for all of you.

Also 100% haben sie es wohl noch nicht identifiziert, was das Problem genau verursacht.
Ich hoffe jedenfalls auf ein Microcode/Bios/Software Update für die Betroffenen, ansonsten muss man eben tauschen (lassen).

Ganon

2017-08-08, 17:40:41

Diese Aussage stammt nicht von AMD sondern, Michael Larabel behauptet AMD hat gesagt ....

Du unterstellst mir AMD-Bashing, aber haust jetzt sowas raus? :ugly: Aber gut, kann natürlich auch deine Meinung dazu sein. Wenn du alles für eine große Lüge hältst, bitte.

Dann erkläre uns Unwissenden doch das Problem, dann wären ja alle Zweifel beseitigt.
Komisch das das bisher noch keiner getan hat.

Wozu soll ich das hier jetzt noch mal verlinken und erklären? Ist doch für dich eh alles nur eine große Lüge. Darfst dich gerne selbst noch mal durch den Thread scrollen.

Ganon

2017-08-08, 17:45:35

Also sehe ich das richtig: Bei einigen frühen Ryzen gab es bei einem Compiler crashes. Bei neueren Ryzen ist das nicht mehr der Fall? Und die, die nicht funktionierten (einzelne CPUs) werden auch noch ausgetauscht? :confused:

So in etwa. Dass der Customer Care alle CPUs austauscht von allen Leuten die sich melden muss sich erst noch großflächig zeigen. Es gibt auch noch genug Leute die auf eine finale Antwort warten, da der AMD Support ja sagt, dass sie das Problem weiter untersuchen. Diverse Leute hoffen noch auf ein Microcode-Fix.

Aber das neure Ryzen CPUs das Problem nicht haben wurde u.a. auch hier im Forum berichtet und auch von Leuten im verlinkten Thread von Post #1. Bis dato fehlte halt nur eine Aussage von AMD dazu.

Wie das Ganze letztendlich ausgeht wird sich dann zeigen. Wer sich jetzt einen Ryzen kauft wird vermutlich das Problem nicht haben. Vorausgesetzt man will überhaupt so eine Last wie Software-Kompilierung überhaupt ausführen.

Menace

2017-08-08, 17:54:27

Dann muss man ja AMD ausdrücklich loben, dass sie sogar die CPUs austauschen. Und wenn die aktuellen Ryzen keine Probleme mehr haben, dann ist das doch perfekt.

Da zweifle ich stark an einem Ryzen-Bug. Eher scheint die Fertigung zu Beginn nicht ganz perfekt gelaufen zu sein.

Welche Compiler waren jetzt betroffen? Alle? Ich meine jetzt mit einem Crash; nicht dass irgendwas nur angezeigt wurde, was ja wohl auch intel hat.

TGKlaus

2017-08-08, 17:54:37

aber haust jetzt sowas raus?

Auch mal die Kommentare dazu gelesen, in denen er zurückrudert?

Wozu soll ich das hier jetzt noch mal verlinken und erklären? Ist doch für dich eh alles nur eine große Lüge.

Dann zeig mir bitte den Post wo du technisch-sachlich etwas erklärt hast.

Du schmeiß nur mit Sachen rum wie:

Na wenn du meinst genau das da raus zu lesen...

Darfst dich gerne selbst noch mal durch den Thread scrollen.

Das kannst du natürlich so interpretieren.

Nicht ein einziges mal sind harte Fakten dabei.

Ganon

2017-08-08, 18:39:06

Dann muss man ja AMD ausdrücklich loben, dass sie sogar die CPUs austauschen. Und wenn die aktuellen Ryzen keine Probleme mehr haben, dann ist das doch perfekt.

Eben. Es war halt bisher unklar an was es nun genau liegt und ob es ein Fehler in der Architektur selbst ist, oder eben ein Fertigungsproblem. Deutet wohl alles auf einen anfängliches Fertigungsproblem hin.

Da zweifle ich stark an einem Ryzen-Bug. Eher scheint die Fertigung zu Beginn nicht ganz perfekt gelaufen zu sein.

So ist es wohl. Aber Fehler ist Fehler, da ja nun nicht wenig Leute betroffen waren.

Welche Compiler waren jetzt betroffen? Alle? Ich meine jetzt mit einem Crash; nicht dass irgendwas nur angezeigt wurde, was ja wohl auch intel hat.

Wenn wir jetzt einfach mal diverse Windows-Berichte ausklammern, weil das "simple Foreneinträge waren", dann konnten das Problem viele "hochrangige" Kernel- und Software-Entwickler mit GCC und Clang nachvollziehen.

Zusätzlich dazu wurden einige Test-Tools entworfen, die das Problem weiter analysiert haben, aber nichts für "hier zum Doppelklick für dich".

Nicht ein einziges mal sind harte Fakten dabei.

Deswegen sagte ich ja: Scrolle einfach durch den Thread. Nur weil du AMDs offizielle Stellungnahme dazu als Lüge verdächtigst, mache ich mir jetzt nicht nur für dich extra Arbeit das alles noch mal zusammenzusuchen, nur damit du das hinterher wieder als Lüge abstellen kannst.

TGKlaus

2017-08-08, 18:51:59

Nur weil du AMDs offizielle Stellungnahme dazu als Lüge verdächtigst, mache ich mir jetzt nicht nur für dich extra Arbeit das alles noch mal zusammenzusuchen ...

Offizielle Stellungnahme von AMD? Kenn ich noch nicht. Verlink mal Bitte.

Falls du (was ich aber für ausgeschlossen halte, da du von offizielle AMD Stellungnahme schreibst) den Artikel von phoronix meinst.
Wie passt das denn zu deinen Aussagen?

a performance marginality problem exclusive to certain workloads on Linux

Ein Bug der unter Linux, FreeBSD, NetBSD, DragonFly BSD, Windows, GCC, Clang, dem Microsoft Compiler und generell überall auftritt

Daedalus

2017-08-08, 19:11:05

amdmatt wrote:

We have been working closely with a small but important subset of Linux users that have experienced segment faults when running heavy or looping compilations on their Ryzen CPU-based systems. The results of our testing and analysis indicate that segment faults can be caused by memory allocation, system configurations, thermal environments, and system marginality when running looping or heavy Linux compile workloads. The marginality is stimulated with very heavy workloads and when the system environment is not ideal. AMD is working with individual users to diagnose the issues.

We are confident that we can help each of you identify the source of the marginality and eliminate the segment faults. We encourage all of our Linux users who are experiencing segment faults under compile workloads to continue working with AMD Customer Care. We are committed to solving this issue for all of you.

und z.B.

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/967913-amd-confirms-linux-performance-marginality-problem-affecting-some-doesn-t-affect-epyc-tr?p=967927#post967927

Über die Sache mit dem MSVC hatte ich mich aber auch gewundert... Konnte ich weder selbst nachvollziehen, noch habe eine seriöse Quelle dazu gefunden. Quellenangaben wären bei so etwas toll!

Rancor

2017-08-08, 20:45:16

AMD sollte mal lieber ordentlich kommunizieren. Finde das schon etwas arm, das man da kaum Infos bekommt.

Ätznatron

2017-08-08, 21:06:59

Über die Sache mit dem MSVC hatte ich mich aber auch gewundert... Konnte ich weder selbst nachvollziehen, noch habe eine seriöse Quelle dazu gefunden. Quellenangaben wären bei so etwas toll!

Du kannst ja selbst entscheiden, wie glaubhaft für dich Behauptungen ohne Quellenangaben sind.

Dino-Fossil

2017-08-08, 21:13:02

AMD sollte mal lieber ordentlich kommunizieren. Finde das schon etwas arm, das man da kaum Infos bekommt.

Ich schätze mal, die haben selbst noch nichts 100% belastbares, dass sie kommunizieren könnten.

Und immerhin haben sie inzwischen klar gesagt, dass sie daran arbeiten und erste Erkenntnisse dazu haben. Es scheint auch einigermaßen sicher, dass du sogar eine Tausch-CPU bekommst, wenn du dich an den Support wendest.

Was erwartest du da gegenwärtig noch groß?

Menace

2017-08-08, 22:31:14

Was erwartest du da gegenwärtig noch groß?

Vielleicht in etwas: Alle ab Mai (?) verkauften Ryzen-CPUs machen KEINE Probleme. Aber wo bliebe da die Sensation? :rolleyes:

Ganon

2017-08-08, 22:33:43

Offizielle Stellungnahme von AMD? Kenn ich noch nicht. Verlink mal Bitte.

Daedalus hat's direkt unter deinem Post zitiert und ich hab's extra für dich rausgesucht:
https://community.amd.com/message/2816382#comment-2816382#2816382

Man suche nach "amdmatt".

Auch interessant ist der Link von Daedalus:

I think the intent was "performance within the chip" (internal signals) not "performance on a benchmark".

...

Wie passt das denn zu deinen Aussagen?

Ich hab mich dazu zwar schon geäußert, aber es ist ja Gewohnheit hier, dass alle Beiträge vor dem Beitrag den mal selbst verfasst, nicht mehr existieren...

Ich kann nicht sagen, warum der AMD-Marketing Mensch das Problem rein auf Linux Workloads legt, da es offensichtlich ist, dass auch mehr Betriebssysteme betroffen sind. Meine Vermutung ist, dass ihm entweder nicht mehr Informationen vorlagen, oder es so erwähnt wird, dass nicht plötzlich alle Windows Nutzer pro forma sich an den AMD Kundensupport wenden, solange man nicht alles 100%ig abgeprüft hat. "Linux Workloads" kann auch schlicht heißen: Der Windows-User kompiliert selten sein ganzes OS neu durch.

Ja, dass auch Windows betroffen ist, habe ich von Aussagen von Nutzern, die das ganze im Linux Subsystem nachvollzogen haben. Wenn du das nicht glaubst, ist OK. Musst du nicht. Vermutlich gilt das Linux Subsystem für Windows auch als "Linux Workload".
"Ihr" könntet das natürlich auch einfach widerlegen, wenn ihr das Problem unter Linux nachvollziehen könnt, aber im Linux Subsystem für Windows nicht. Aber wichtig ist's jetzt auch nicht mehr, da AMD im Prinzip alles gesagt hat.

Aber es ist sicherlich verständlich, dass AMD den Ball erst mal flach halten will.

Ihr könnt natürlich auch weiterhin Linux die Schuld an allem geben. Ist mir auch egal. Als Randnotiz kann man hier erwähnen, dass Datenverlust auf Samsung SSDs auch nur unter Linux aufgetreten ist und nicht unter Windows. Das lag letztendlich aber daran, dass die SSD Firmware ein Feature angepriesen hat, welches in der Firmware fehlerhaft implementiert war. Warum also nur Linux? Weil Windows das entsprechende Feature gar nicht erst unterstützt hatte.

Dass ein Bug also nur unter einem Betriebssystem auftritt muss nicht heißen, dass etwas in dem einen Betriebssystem kaputt ist.

Vielleicht in etwas: Alle ab Mai (?) verkauften Ryzen-CPUs machen KEINE Probleme. Aber wo bliebe da die Sensation? :rolleyes:

Ich könnte mir vorstellen, dass AMD gerade das herauszufinden versucht und allgemein, wie das an sich passieren konnte.

Ätznatron

2017-08-08, 22:54:04

Wichtig ist, die Gerüchteküche am Laufen zu halten:

Ich kann nicht sagen, warum der AMD-Marketing Mensch das Problem rein auf Linux Workloads legt, da es offensichtlich ist, dass auch mehr Betriebssysteme betroffen sind....

Was du versuchst, dadurch zu bekräftigen:

Ja, dass auch Windows betroffen ist, habe ich von Aussagen von Nutzern, die das ganze im Linux Subsystem nachvollzogen haben....

Eine Erklärung dafür bietest du natürlich auch:

Aber es ist sicherlich verständlich, dass AMD den Ball erst mal flach halten will....

Schuld sind immer die anderen:

Ihr könnt natürlich auch weiterhin Linux die Schuld an allem geben. Ist mir auch egal....

Probleme? Wenn, dann bei allen:

Dass ein Bug also nur unter einem Betriebssystem auftritt muss nicht heißen, dass etwas in dem einen Betriebssystem kaputt ist...

Und zum Abschluss ein Ausflug in die Welt der Fantasie:

Ich könnte mir vorstellen, dass AMD gerade das herauszufinden versucht und allgemein, wie das an sich passieren konnte....

Ganon

2017-08-08, 23:02:08

Wichtig ist, die Gerüchteküche am Laufen zu halten:
Was du versuchst, dadurch zu bekräftigen:
Eine Erklärung dafür bietest du natürlich auch:
Schuld sind immer die anderen:
Probleme? Wenn, dann bei allen:
Und zum Abschluss ein Ausflug in die Welt der Fantasie:

Es ist natürlich auch dein gutes Recht alles nicht zu glauben und dir deinen ganz eigenen Reim aus der ganzen Situation zu machen. :)

Ätznatron

2017-08-08, 23:07:35

Es ist natürlich auch dein gutes Recht alles nicht zu glauben und dir deinen ganz eigenen Reim aus der ganzen Situation zu machen. :)

Mein zynischer eigener Reim: Da hat Linux mal wieder eine große Chance verpasst.

aufkrawall

2017-08-08, 23:33:29

Es ist natürlich auch dein gutes Recht alles nicht zu glauben und dir deinen ganz eigenen Reim aus der ganzen Situation zu machen. :)
Aber ist es auch sein Recht, den Thread mit esoterischem Fake-News Geschwurbel zu hijacken? Das ist hier offenbar gerade mal wieder die Masche, wie sie Fanboys in Foren halt immer abziehen.

Daedalus

2017-08-09, 01:16:54

Nachdem gcc mit gcc kompilieren gefühlt stabil ist/war, habe ich mal wieder Mesa versucht zu bauen, nur diesmal mit clang. Stock schlagen etwa 50% aller Vorgänge fehl, kann ich als Test nur empfehlen. RAM- (und IF-) Takt mildern das Problem ab. SOC Spannung hilft auch, aber wirklich stabil wird es nicht. Das ganze unter einem Ubuntu 17.04 mit Kernel 4.10. Ein Low-Latency-Kernel hilft auch nicht bzw. hat bei überhaupt keine Verbesserung gebracht (4.11.12-lowlatency).

Isen

2017-08-09, 01:50:20

RAM- (und IF-) Takt mildern das Problem ab. SOC Spannung hilft auch,

Jepp...
Aber darauf kam ich schon letzten Monat recht schnell.

Dem Problem kommt man sehr nahe, wenn man nur die Sub-Timings der Default Werte Händisch optimiert.
Erhöht man dann nur die Spannungen der Default-Werte (Takt, SoC, vDIMM, PLL ) ist man am Problem angekommen und hat den Verursacher gefunden.

Eher gesagt hat man 2 Ursachen gefunden. Einerseits das Bios bzw. AGESA 1004/1006 andererseits die Internen Latenzen der CPU.

Was machte das AGESA 1006 denn so anders, als das 1004? - Nun, gewisse Optimierungen für höheren Speichertakt, wo die internen Latenzen entsprechend angepasst wurden, die frühe Modelle die vom Band liefen, so nicht verkraften.

D.h. Ein defekt ist es definitiv nicht, aber die nachträglichen Optimierungen sind zu viel, diese packt der Chip nicht, obwohl es die späteren Exemplare schaffen.

Fazit: Die Fertigung hat definitiv zu Beginn ihre indirekten Probleme gehabt, die aber erst zutage kamen, nachdem man Optimierungen für höheren Speichertakt/IF-Takt durchführte...

Gut möglich, dass das mittels Microcode behoben wird. Diese Prozessoren sind dann vermutlich jene Exemplare, wo man schwer hohe Taktraten beim Speicher/IF schafft und man genauso gegen eine Taktmauer rennt, wie beim Core Takt > 4Ghz. und man schlussendlich als solches bezeichnet, wie man es eh seit Ewigkeiten bei GPUs als auch CPUs und RAM tut: Krüppel erwischt, der mag nicht höher.

AMD wird vermutlich nun schauen, wo die Limits sitzen und wie sie gesetzt werden müssen, bei jenen Exemplaren die das Problem haben.
Ist das nicht möglich, wird eben gegen jene ausgetauscht die später vom Band liefen.

Boris

2017-08-09, 02:16:27

Wie kann man das eigentlich am besten bzw. überhaupt unter Windows testen? Dann würde ich das auch mal machen, hab auch einen der ersten Ryzen 7.

Isen

2017-08-09, 02:36:58

Wie kann man das eigentlich am besten bzw. überhaupt unter Windows testen? Dann würde ich das auch mal machen, hab auch einen der ersten Ryzen 7.

am einfachsten:

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

Downloaden: ryzen_segv_test_20170712_win.zip

Launcher.exe starten
6 > ENTER
2500000 > ENTER

Malabolge

2017-08-09, 07:42:45

Aber ist es auch sein Recht, den Thread mit esoterischem Fake-News Geschwurbel zu hijacken? Das ist hier offenbar gerade mal wieder die Masche, wie sie Fanboys in Foren halt immer abziehen.

AMD verkauft womöglich kaputte Chips...
Unheimlich wie faktisch und auf Beweisen hier Argumentiert wird :wink:;)

Daedalus

2017-08-09, 08:50:10

Jepp...
Aber darauf kam ich schon letzten Monat recht schnell.

Dem Problem kommt man sehr nahe, wenn man nur die Sub-Timings der Default Werte Händisch optimiert.
Erhöht man dann nur die Spannungen der Default-Werte (Takt, SoC, vDIMM, PLL ) ist man am Problem angekommen und hat den Verursacher gefunden.

Eher gesagt hat man 2 Ursachen gefunden. Einerseits das Bios bzw. AGESA 1004/1006 andererseits die Internen Latenzen der CPU.

Was machte das AGESA 1006 denn so anders, als das 1004? - Nun, gewisse Optimierungen für höheren Speichertakt, wo die internen Latenzen entsprechend angepasst wurden, die frühe Modelle die vom Band liefen, so nicht verkraften.

D.h. Ein defekt ist es definitiv nicht, aber die nachträglichen Optimierungen sind zu viel, diese packt der Chip nicht, obwohl es die späteren Exemplare schaffen.

Fazit: Die Fertigung hat definitiv zu Beginn ihre indirekten Probleme gehabt, die aber erst zutage kamen, nachdem man Optimierungen für höheren Speichertakt/IF-Takt durchführte...

Gut möglich, dass das mittels Microcode behoben wird. Diese Prozessoren sind dann vermutlich jene Exemplare, wo man schwer hohe Taktraten beim Speicher/IF schafft und man genauso gegen eine Taktmauer rennt, wie beim Core Takt > 4Ghz. und man schlussendlich als solches bezeichnet, wie man es eh seit Ewigkeiten bei GPUs als auch CPUs und RAM tut: Krüppel erwischt, der mag nicht höher.

AMD wird vermutlich nun schauen, wo die Limits sitzen und wie sie gesetzt werden müssen, bei jenen Exemplaren die das Problem haben.
Ist das nicht möglich, wird eben gegen jene ausgetauscht die später vom Band liefen.

Das Problem trat schon vor AGESA 1.0.0.6 auf. Aber ich werd gleich mal 1.0.0.4 testen.

am einfachsten:

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

Downloaden: ryzen_segv_test_20170712_win.zip

Launcher.exe starten
6 > ENTER
2500000 > ENTER

Bei dem Tool würde ich vorsichtig sein. Was man so liest, hat es einige false positives gegeben. Auch bridgman hatte afaik dazu etwas geschrieben.

Ich würde es in einer VM testen und Mesa im Loop kompilieren. Wobei der Aufwand nicht viel geringer ist, als ein Linux auf einem USB Drive zu installieren.