News Hat Ryzen Probleme mit bestimmtem FMA3-Code?

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.446
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Der Entwickler Alexander “Mysticial” Yee ist bei seinem selbst entwickelten Benchmark namens Flops auf einen Fehler gestoßen, der mit seinem AMD-Ryzen-System zum sofortigen Absturz des gesamten PCs führt. Dabei handelt es sich um hochoptimierten Code, der Single-Precision 128-bit FMA3-Befehle verwendet. Wem nun ein Horrorszenario vom Schlage des Phenom-TLB-Bugs vor dem inneren Auge abläuft, der kann (vermutlich) beruhigt werden.
(…)

» Artikel lesen
 
Unter Linux habe ich gelesen soll der selbe Benchmark durchlaufen.
 
Unter Linux habe ich gelesen soll der selbe Benchmark durchlaufen.
Das kann schlicht daran liegen, dass unter Linux ein anderer Compiler zum Einsatz kommt. Wenn ich das richtig gelesen habe, wird die Windows-Binary mit MS Visual Studio übersetzt, die Linux-Version dagegen sicher nicht ;) Der Code ist also nicht vergleichbar; womöglich nutzt das Linux-Binary die kritische Befehlsfolge einfach nicht.

Auffällig ist auch, dass alle bei HWBot getesteten Systeme - und das betroffene System bei uns im Forum - ein ASUS-Mainboard hatten... *kopfkratz
 
Unser Ryzen mit Gigabyte-Board stürzt auch ab, auch im OC-Modus.
 
Andres Board als das ASUS C6H steht mir leider nicht zur Verfügung um das gegen zu testen.

Scheint aber nicht auf ASUS Boards beschränkt zu sein:

I tried it on my Gigabyte AB350-Gaming 3-CF and my display went completely black. So this is definitely not an ASUS only thing.

Und The Stilt dazu auch in dem Thread:

The issue with Flops was found and fixed in the beginning of february.
The current µcode version dates to 01/27/2017, so the fix is obviously not included yet (due to the time required for validation).
Flops is only affected when the SMT is enabled, so disabling the SMT can be used as a temporary work-around (until the actual fix arrives).

Der hat da wohl den Fix schon aktiv, am Ende ist ein Posting wo es erfolgreich durchgelaufen ist.
 
Zuletzt bearbeitet:
Vom Intel Skylake zum Beispiel sind aktuell 172 Bugs dokumentiert.

Könnt ihr da mal bitte im Text den Link zur Skylake Errata setzen? Aktuell verlinkt ihr da auf die 4th Gen und Skylake ist ja 6th Gen :)
Es würde mich nur mal interessieren, wie es bei Skylake aussieht, kann aber bei Intel auf der Seite nichts finden.

Merci
 
Oops, sorry. Wink lervechselt ;D Ist gefixt.
 
Aussage stimmt ohne SMT läuft das durch:

 
Aus dem Golem Artikel:

Auch wir konnten den Absturz mit einer Ryzen 7 1800X auf dem Mainboard MSI X370 XPower Gaming Titanium nachstellen

betrifft also nicht nur ASUS.

Der Absturz tritt bei uns sowohl mit dem von Yee selbst bereitgestellten Binärdateien auf als auch mit der von uns kompilierten Anwendung. Der verwendete Compiler und die Toolchain scheinen darüberhinaus hier nicht das eigentliche Problem zu sein. Denn wir können ebenfalls reproduzierbar einen Absturz mit Binärdateien verursachen, die wir unter Linux mit MinGW für Windows crosskompiliert haben.

Am Compiler liegt es also ebensowenig.

Der Fehler ist wohl außerdem auf Windows beschränkt. Unter Linux verursacht die Anwendung unabhängig von der SMT-Nutzung bei uns keine Abstürze. ...
... Ebenso fehlerfrei ist die Ausführung der Windows-Binärdateien unter Linux mit Hilfe des Windows-API-Nachbaus von Wine.

Zusammen mit der W7 Supportkeule ist der Workaround doch wohl klar.
Einfach kein Windows mehr benutzen.

Dass der Absturz wie beschrieben nur unter bestimmten Umständen bei der Verwendung von Windows 10 auftritt, deutet daraufhin, dass es sich nicht um einen Fehler der Hardware selbst handelt, sondern eben um einen sehr spezifischen Fehler in Verbindung mit der SMT-Verarbeitung von Windows.

Ist doch grotesk.
MS will Win 7 absägen, doch ausgerechnet das wär hier wieder mal das Mittel der Wahl.
 
Golem hat ja nur das zusammengefasst - wie heise auch - was im HWBOT Forum gefunden wurde und es dann selber nach vollzogen.
 
FX-8350@FX-9590 , Haswell.exe:
Single-Precision - 128-bit FMA3 - Fused Multiply Add:
Dependency Chains = 12
Result = 595.2
FP Ops = 3072000000000
seconds = 12.0334
GFlops = 255.289

Die Piledriver.exe ist etwas schneller:

Single-Precision - 128-bit FMA3 - Fused Multiply Add:
Dependency Chains = 12
Result = 595.2
FP Ops = 3072000000000
seconds = 12.0247
GFlops = 255.474

Single-Precision - 128-bit FMA4 - Fused Multiply Add:
Dependency Chains = 12
Result = 595.2
FP Ops = 3072000000000
seconds = 11.8941
GFlops = 258.28

Den Benchmark kannte ich noch nicht, gefällt mir. :)
 
naja, so ein Wahnsinnsbohei wird darum ja nicht gemacht. Und was dran ist ja offenbar auch, sonst würde AMD sagen "nee, ist ein Problem von zu doofen Usern" oder sowas. Man muß jetzt den Fix mal abwarten udn Tests damit machen. Wenn der die Performance stark einschränken würde, dann wäre es wirklich TLB 2.0, aber da es nur FMA3 betrifft, dürfte ein performanceeinschränkender Workaround nur in diesen seltenen Fällen zur Anwendungen kommen und somit die allgemeinen User kaum betreffen. Aber mal abwarten, was dann für ein Wirbel gemacht wird oder auch nicht.
 
Neue BIOS Versionen mit neuem AGESA Code stehen ja kurz bevor, ggf hat sich das dann in Kürze erledigt,
 
Die Empfehlung von AMD den HPET abzuschalten finde ich nicht durchdacht - damit handelt man sich nur Probleme ein.

RTC/PIT wurden vor vielen Jahren nicht umsonst abgelöst; übrigens war damals AMD die treibende Kraft hinter diesem Schritt.
 
Zurück
Oben Unten