Hat Ryzen Probleme mit bestimmtem FMA3-Code? (Update 2)

Update 05.04.2017 Inzwi­schen schei­nen die ers­ten BIOS-Updates mit aktua­li­sier­ten AGE­SA-Micro­codes aus­ge­rollt zu wer­den. Heu­te etwa ist bei ASUS für das Prime B350-PLUS das Beta-BIOS 0605 erschie­nen. Dabei wur­de der AGE­SA-Code auf 1.0.0.4A aktua­li­siert. In ande­rer Schreib­wei­se, wie sie z.B. von AIDA64 aus­ge­le­sen wird, heißt das “Micro­code Update Revi­si­on 800111C” statt 8001105 und “SMU Firm­ware Revi­si­on 25.70.0” statt 25.59.0.

Wie bei uns im Forum nach­zu­le­sen, läuft das kri­ti­sche Test­tool “flops” für Has­well nun durch ohne einen Blackscreen zu ver­ur­sa­chen. Ins­ge­samt scheint die Leis­tung mini­mal höher zu sein. Nur in Sachen “kri­ti­sche Spei­cher-Modu­le” scheint sich (noch) nichts getan zu haben.

Update vom 20.03.2017: Inzwi­schen hat hei­se eine offi­zi­el­le Bestä­ti­gung zum mut­maß­li­chen FMA3-Bug in Ryzen von AMD erhal­ten (sie­he Ori­gi­nal­mel­dung unten). Man habe den Feh­ler iden­ti­fi­ziert und arbei­te an einer Lösung, damit Main­board-Her­stel­ler so bald wie mög­lich ein BIOS-Update zur Ver­fü­gung stel­len können:

“We are awa­re of sel­ect ins­tances whe­re FMA code can result in a sys­tem hang. We have iden­ti­fied the root cau­se and will soon release BIOS updates to mother­board ven­dors that will resol­ve the issue. Plea­se watch for new BIOS updates from your mother­board ven­dor to incor­po­ra­te the­se changes.”

In der Zwi­schen­zeit hat­te Golem eige­ne Tests durch­ge­führt und dabei fest­ge­stellt, dass der Feh­ler aus­schließ­lich unter Win­dows auf­tritt – und zwar sowohl mit dem fer­ti­gen Bina­ry als auch mit selbst kom­pi­lier­ten Ver­sio­nen und sogar sol­chen, die mit einem ande­ren Com­pi­ler erstellt wor­den sind, was einen Com­pi­ler-Bug aus­schloss –, wohin­ge­gen der Feh­ler unter Linux nicht zum Vor­schein kam. Da der Absturz zudem nur bei akti­vier­tem SMT beob­ach­tet wer­den konn­te, tipp­te Golem auf einen SMT-Feh­ler oder eine ‑Inkom­pa­ti­bi­li­tät in Win­dows 10 und nicht auf einen Bug in Ryzen. Das wäre nun mit der off­zi­el­len Bestä­ti­gung durch AMD hin­fäl­lig. Da es aber noch immer kei­nen Revi­si­on Gui­de gibt zu Sum­mit Ridge, blei­ben die genaue­ren Ursa­chen und die Maß­nah­men zur Behe­bung wei­ter im Dunkeln.

Ori­gi­nal­ar­ti­kel vom 15.03.2017
Der Ent­wick­ler Alex­an­der “Mys­ti­cial” Yee ist bei sei­nem selbst ent­wi­ckel­ten Bench­mark namens Flops auf einen Feh­ler gesto­ßen, der mit sei­nem AMD-Ryzen-Sys­tem zum sofor­ti­gen Absturz des gesam­ten PCs führt. Dabei han­delt es sich um hoch­op­ti­mier­ten Code, der Sin­gle-Pre­cis­i­on-128-bit-FMA3-Befeh­le ver­wen­det. Nach sei­nem Pos­ting bei HWBot haben eini­ge User den Feh­ler nach­ge­stellt, sodass man aus­schlie­ßen kann, dass es ein indi­vi­du­el­ler Defekt sei­nes CPU-Exem­plars oder ein Bug sei­nes Main­boards ist. Nur ob der Absturz auf­grund eines Bugs im Ryzen-Pro­zes­sor geschieht oder auf­grund eines feh­ler­haf­ten Codes durch einen Bug im Com­pi­ler, ist noch nicht abschlie­ßend geklärt, da sich AMD laut Hei­se dazu noch nicht geäu­ßert hat.

Wem nun ein Hor­ror­sze­na­rio vom Schla­ge des Phe­nom-TLB-Bugs vor dem inne­ren Auge abläuft, der kann (ver­mut­lich) beru­higt wer­den. Der TLB-Bug — oder bes­ser gesagt der dar­auf fol­gen­de leis­tungs­min­dern­de Work­around — bestraf­te prak­tisch jeg­li­che Soft­ware, da in einem moder­nen Betriebs­sys­tem mit vir­tu­el­ler Adress­ver­wal­tung jedes Pro­gramm von einem funk­tio­nie­ren­den Trans­la­ti­on-Loo­ka­s­i­de-Buf­fer pro­fi­tiert. Wenn hier ein Bug durch Deak­ti­vie­ren von Fea­tures umschifft wer­den muss – wirk­lich fixen kann man einen Feh­ler ja nur mit einem neu­en Step­ping – so wirkt sich das natür­lich nega­tiv auf die Leis­tung aus.

Soll­te sich wirk­lich ein Bug in die FMA3-Sek­ti­on der Ryzen-FPU geschli­chen haben, der per AGE­SA-Micro­code-Update umschifft wer­den müss­te, so wäre das zwar ärger­lich für AMD, für den Anwen­der unter dem Strich aber nur wenig rele­vant, von der Trag­wei­te her eher ver­gleich­bar mit dem IDIV-Bug des Llano, als mit dem TLB-Bug des Phe­nom. Damals hat­te AMD sei­ner K10-basier­ten APU Llano eine Hard­ware-IDIV-Ein­heit spen­diert; die jedoch unter bestimm­ten Umstän­den feh­ler­haft arbei­te­te. Daher muss­te AMD den neu­en Pfad per BIOS-Update wie­der deak­ti­vie­ren, was die Leis­tung bei den äußerst sel­ten vor­kom­men­den Inte­ger-Divi­sio­nen wie­der auf K10-Niveau redu­zier­te. Ähn­lich liegt der Fall bei Ryzen. Kaum eine Soft­ware nutzt FMA3-Code.

Ver­wun­der­lich wäre es den­noch – soll­te es sich wirk­lich um einen Bug in Ryzens FMA3-Ein­heit han­deln –, da Fused-Mul­ti­ply-Add mit 3 Ope­ran­den nichts Neu­es ist bei AMD-Pro­zes­so­ren, im Gegen­satz zu IDIV bei Llano damals. Schon Bull­do­zer unter­stütz­te Fused-Mul­ti­ply-Add, und zwar nicht nur das simp­le FMA3, son­dern sogar das vom ein­ge­stampf­ten SSE5-Pro­jekt abge­lei­te­te FMA4. Seit Ryzen ver­zich­tet AMD jedoch auf FMA4 und beschei­det sich wie Intel mit FMA3.

Dass kom­ple­xe Gebil­de wie Pro­zes­so­ren unzäh­li­ge Feh­ler auf­wei­sen, ist nor­mal. Vom Intel Has­well zum Bei­spiel sind aktu­ell 172 Bugs doku­men­tiert, von Sky­la­ke 141. Zu AMDs Ryzen ist lei­der noch kein Revi­si­on Gui­de online. Unge­wöhn­lich ist eher, dass es so ein Bug tat­säch­lich auch mal repro­du­zier­bar in die freie Wild­bahn schafft. Nor­ma­ler­wei­se wird der Groß­teil davon bereits in der Test­pha­se neu­tra­li­siert oder die Umstän­de sind so uto­pisch, dass sie in der Pra­xis so gut wie nie auf­tre­ten. Aber hier merkt man dann wohl doch die kom­plett tau­fri­sche Architektur.