SegFault-Bug: AMD bestätigt Ryzen-Fehler beim Kompilieren unter Linux

[Kaj G. (Firma: RUB) (bloody)]

In Anlehnung an diesen Thread ( 
Beitrag "[WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading" ) diesmal AMD

SegFault-Bug: AMD bestätigt Ryzen-Fehler beim Kompilieren unter Linux
https://www.heise.de/newsticker/meldung/SegFault-Bug-AMD-bestaetigt-Ryzen-Fehler-beim-Kompilieren-unter-Linux-3796688.html

Unter Linux kann es beim Kompilieren von Software auf einem
AMD-Ryzen-Prozessor (Fassung AM4) zu Problemen kommen: Unter
extremer CPU-Last treten dann "Segmentation Faults" (SegFaults)
auf, der Kompilierungsvorgang scheitert.

...

Das Problem tritt dabei ausschließlich unter Linux und beim
Verwenden eines Prozessors aus der Ryzen-Consumer-Reihe auf.
Windows-Nutzer sind nicht betroffen.

[Mike J. (linuxmint_user)]

Ich will nur einen mit integrierter Grafik. Vielleicht ist der Bug ja 
dann schon weg in den neueren Prozessoren mit GPU.
Da wird es aber bestimmt auch bald ein Micro-code Update geben.

[T.roll (Gast)]

Kaj G. schrieb:
> Das Problem tritt dabei ausschließlich unter Linux und beim
> Verwenden eines Prozessors aus der Ryzen-Consumer-Reihe auf.
> Windows-Nutzer sind nicht betroffen.

Der Teil ist falsch. Der Fehler tritt bei jedem Betriebssystem auf.

[Rolf R. (dankobum)]

CPUs, die ab einer bestimmten Kalenderwoche produziert wurden, haben das 
Problem nicht mehr. AMD bietet betroffenen Kunden einen Austausch an. 
Siehe auch hier:

https://community.amd.com/thread/215773?start=945&tstart=0

und

https://www.phoronix.com/forums/forum/phoronix/general-discussion/967913-amd-confirms-linux-performance-marginality-problem-affecting-some-doesn-t-affect-epyc-tr/page28

Meine Fragen hierzu sind:
Was war denn bis zu der bestimmten Kalenderwoche das Problem?
Wie wurde das Problem von AMD gefunden?
Wie wurde das Problem beseitigt?

Ich habe die ganze Sache so einigermassen verfolgt und trotzdem sind 
diese Fragen bisher unbeantwortet.

[Fliege one (Gast)]

Verunreinigung der Wafer durch Fliegenscheisse

[(prx) A. K. (prx)]

Rolf R. schrieb:
> Was war denn bis zu der bestimmten Kalenderwoche das Problem?

Der Chip wahrscheinlich ;-). Ab Woche  X dürfte es eine neue Version 
sein. Der Rest liegt in der Tiefe der Details der Mikroarchitektur. Die 
ist heutzutage dermassen kompliziert, dass es wenig Sinn ergibt, das 
genauer zu erklären. Und offengelegt werden Mikroarchitekturen en detail 
nicht. Betriebsgeheimnis.

[Rolf R. (dankobum)]

A. K. schrieb:
> Rolf R. schrieb:
>> Was war denn bis zu der bestimmten Kalenderwoche das Problem?
>
> Der Chip wahrscheinlich ;-). Ab Woche  X dürfte es eine neue Version
> sein. Der Rest liegt in der Tiefe der Details der Mikroarchitektur. Die
> ist heutzutage dermassen kompliziert, dass es wenig Sinn ergibt, das
> genauer zu erklären. Und offengelegt werden Mikroarchitekturen en detail
> nicht. Betriebsgeheimnis.

Die ganze Sache war ein grosse Schmach für AMD. Da wäre es doch eine 
super gute Meldung gewesen, zu sagen: "Wir haben das Problem xy erkannt 
und behoben. Ab Kalenderwoche X der Produktion gibt es das Problem nicht 
mehr." Stattdessen bleiben die Kunden im Unklaren und die Betroffenen 
können sich eine Austausch-CPU besorgen.

[Mike J. (linuxmint_user)]

Rolf R. schrieb:
> und die Betroffenen
> können sich eine Austausch-CPU besorgen.

Weshalb lösen die das nicht eifnach mit einem Mikrcode-Updaten, welches 
beim Systemstart in die CPU geladen wird?Intel macht es doch ebenfalls 
so wenn mal etwas im CPU vermurkst ist ... so etwas komplexes kann man 
doch nie perfekt in begrenzter Zeit designen. Es sei denn der Kunde 
wartet 10 Jahre auf die nächste CPU und zahlt den Debugingaufwand.

[Gerd E. (robberknight)]

Mike J. schrieb:
> Weshalb lösen die das nicht eifnach mit einem Mikrcode-Updaten, welches
> beim Systemstart in die CPU geladen wird?

Vielleicht kann man dieses konkrete Problem nicht so einfach mit einem 
Mikrocode-Update lösen?

Bei AMD gibt es soweit ich weiß auch nachladbare Mikrocode-Updates. Wenn 
es damit ohne gravierende Nebenwirkungen lösbar gewesen wäre, hätten die 
das sicher getan. Denn ein Austausch mit Einsenden etc. ist alleine 
schon durch die weltweite Logistik ein riesiger finanzieller Aufwand.

[(prx) A. K. (prx)]

Nachladbarer Microcode kann m.E. nur 2 Probleme lösen.

- Fehler in bestimmten Befehlen, insbesondere solche, die in Microcode 
ausgeführt werden. Dynamisch betrachtet sind das relativ wenige. Die 
meisten Befehle sind nicht Microcode.

- Fehler bei einer ganz bestimmten Optimierung oder bei einer neuen 
Feature des Befehlssatzes. Da kann man die schlicht abschalten. Intel 
tat das beispielsweise bei den neuen Befehlen der ersten Generation vom 
Haswell zu spekulativer Vermeidung zeitraubender Nebeneffekte von Locks. 
Die wurden schlicht wieder abgeschaltet, evtl  schon per BIOS, ohne 
Microcode Patch

Was aber nicht geht: Fehler, die in einer seltenen und daher in den 
internen Test übersehenen oder nicht auftretenden Kombination bestimmter 
Randbedingungen essentieller Grundbestandteile des Cores auftreten. 
Beispielsweise wenn ganz bestimmte Zustände der Inhalte der L1 und L2 
Caches in Verbindung mit einem bestimmten Zeitverhalten zu falschen 
Daten führen. Den L2 Cache abzuschalten würde das dann vielleicht lösen, 
ist aber nicht wirklich eine Option.

[egal (Gast)]

Ach was hier wieder für ein Zirkus gemacht wird wegen eines Bugs. Ich 
zitiere mal einen User Kommentar dazu:

"Ist doch durch einfachen OS-Patch lösbar (ohne Nachteile für den 
Nutzer)

Ich wundere mich, dass immer noch über die Ursache des Bugs spekuliert 
wird, und darüber, ob eine Lösung möglich ist.

Jedenfalls wurde schon in einem frühen Kommentar erwähnt, dass Matt 
Dillon das Problem unter DragonFly-BSD analysiert hat. Seine 
Erkenntnisse sind seit einigen Tagen auch in den FreeBSD-Kernel 
eingegangen und haben das Problem gelöst.

Die Ursache scheint ein komplexes Zusammenwirken von bestimmten 
Operationen und Interrupts zu sein, aber nur dann wenn Speicheradressen 
in der obersten Page des User-Memory benutzt werden.

Die Lösung ist ganz einfach: Die oberste Page des (virtuellen) 
User-Memory wird nicht benutzt, d.h. das Ende des User-Memory wird 
einfach auf eine Page unter dem adressierbaren Limit gesetzt.

Das verändert weder das Laufzeit-Verhalten, noch beeinträchtigt es die 
Speichernutzung, mal abgesehen von einer um eine Page kleineren 
maximalen User-Prozess-Größe, die aber bei einem 64 Bit-Prozessor völlig 
irrelevant ist.

Das Problem ist also trivial umgehbar, und wahrscheinlich ist das auch 
der Grund, dass Windows keine Probleme damit hatte: Anscheinend wird 
dort die kritische (virtuelle) Adresse im Normalfall nicht benutzt."

siehe
https://www.heise.de/newsticker/meldung/SegFault-Bug-AMD-bestaetigt-Ryzen-Fehler-beim-Kompilieren-unter-Linux-3796688.html