AMD bevestigt Ryzen-segmentatiefouten bij Linux-workloads

AMD heeft bevestigd dat zijn Ryzen-processors segmentatiefouten genereren op Linux-systemen. De fouten doen zich voornamelijk voor bij zware compilatietaken als deze in groten getale naast elkaar worden uitgevoerd.

Volgens Phoronix, dat de bevestiging van AMD ontving, werkt de processorfabrikant samen met getroffen klanten om het probleem op te lossen. AMD noemt het een 'performance marginality problem exclusive to certain workloads on Linux'. Volgens Phoronix doet het probleem zich echter mogelijk ook voor op andere Unix-achtige systemen. Er zouden echter nog aanvullende tests nodig zijn om vast te stellen of dat inderdaad zo is.

Er verschenen in april al berichten op het Gentoo-forum en in mei op het AMD-forum en Reddit. Gebruikers melden dat de problemen zich bijvoorbeeld voordoen bij het uitvoeren van parallelle builds, waarbij het systeem na verloop van tijd crasht of opnieuw start. AMD laat weten dat de problemen zich niet voordoen bij Epyc- of Threadripper-cpu's. Ook zouden er geen bepaalde specifieke combinaties van processor en moederbord zijn waarbij de problemen voornamelijk voorkomen.

Phoronix heeft eerder stresstests uitgevoerd en er is een Google-document in het leven geroepen om de resultaten bij te houden. De site adviseert getroffen gebruikers om contact op te nemen met de klantenservice van AMD.

Afbeelding via Phoronix

Reacties (43)

[Loggedinasroot]

Dit lijkt me toch een hardware iets te zijn.
Ook bij de RMA gaat AMD testen met de configuratie van de gebruiker. Dus hetzelfde ram/mobo/ssd etc. Vervolgens krijgen ze een cpu die geen segfaults meer produceert.

[JackBol]

Een segfault treedt op wanneer het OS een stuk memory probeert de lezen/uitvoeren waar het geen toegang to heeft. De Ryzen CPU heeft een bepaald virtual memory model bij bijbehorende paging instructies. De kernel moet dit model en instructies correct ondersteunen, anders gaat het dus mis.

Het betekent niet dat de Ryzen CPU een hardware probleem heeft, enkel dat de Linux kernel momenteel geen goede implementatie heeft van de Ryzen MMU. De oplossing is waarschijnlijk een kernel patch.

Overigens had AMD dit wel beter kunnen testen in een eerder stadium.

[84hannes]

Overigens had AMD dit wel beter kunnen testen in een eerder stadium.

Zonder de exacte omstandigheden waaronder deze fout optreedt te weten is dit een gedurfde uitspraak. Gezien de complexiteit van hard- en software is niet uit te sluiten dat dit probleem alleen voorkomt bij de deling van twee cijfers die co-prime zijn op een tijdstip waarbij de unix timestamp is ms deelbaar is door 77 maar niet door 33, op een Linuxinstallatie die mmx extensies wel ondersteund maar sse niet, op een computer waarbij hyperthreading uitstaat maar fastboot wel geactiveerd is.

[Reactie gewijzigd door 84hannes op 23 juli 2024 01:39]

[JackBol]

[...]

Zonder de exacte omstandigheden waaronder deze fout optreedt te weten is dit een gedurfde uitspraak. Gezien de complexiteit van hard- en software is niet uit te sluiten dat dit probleem alleen voorkomt bij de deling van twee cijfers die co-prime zijn op een tijdstip waarbij de unix timestamp is ms deelbaar is door 77 maar niet door 33, op een Linuxinstallatie die mmx extensies wel ondersteund maar sse niet, op een computer waarbij hyperthreading uitstaat maar fastboot wel geactiveerd is.

Het probleem treedt op bij hoge belasting wanneer ASLR en SMT enabled zijn. Dat is de default configuratie voor een Linux Kernel. Bij lange na niet zo exotisch als je aangeeft.

[Reactie gewijzigd door JackBol op 23 juli 2024 01:39]

[Jmoerman]

(Het treed ook op als ASLR en SMP uitgeschakeld zijn.)

[MSalters]

En voor ASLR is dat logisch. Windows heeft ook ASLR maar is immuun. En ASLR is uiteindelijk ook maar een kwestie van welke code je waar laadt. Verschillende programma's laden toch al op verschillende locaties, het enige verschil is dat met ASLR hetzelfde programma ook op verschillende locaties geladen kan worden.

SMT (AMD's naam voor hyperthreading) is significant complexer. In dat geval heb je 2 runnende threads per core. Ryzen moet die 2 threads fysiek swappen op de ene core, terwijl Linux bepaalt welke 2 threads moeten runnen. Dat is inherent een wisselwerking, en kan potentieel een timing issue hebben. Wat als Ryzen tussen 2 threads swapt net op het moment dat Linux een thread descheduled?

[Loggedinasroot]

Hoe komt het dan dat voornamelijk de eerste batches dit probleem heeft en dat ze nu wel goede chips maken. Als het een software patch is kunnen ze dit gewoon uitbrengen en hoeven ze ook niet dmv rma cpu's te vervangen lijkt me.

[JackBol]

Volgens mij is er geen nieuwe Ryzen stepping. Er is dus geen silicon aanpassing geweest.
Misschien zit er nieuwe microcode in de RMA'ed CPUs.

[Loggedinasroot]

Microcode kun je ook gewoon updaten via de linux kernel en anders met bios toch?

[JackBol]

Ja precies, een hardware RMA zou dus niet nodig hoeven te zijn.
Het enige wat ik me kan voorstellen is dat er nog geen BIOS'en zijn met de nieuwe microcode of dat de microcode patch nog niet beschikbaar is in het veld. En dat ze het daarom via de 'fabriek' doen, waar de de CPUs gewoon op een bank kunnen flashen.

[j1b2c3]

Waar mensen werken worden fouten gemaakt, wees blij dat het met een microcode update of kernel patch oké is. Het is een nieuwe architectuur , niet met de focus op Linux maar op Windows machines. Threthripper is voor servers en Linux getest en heeft het probleem niet

[Alfa1970]

Threthripper is voor servers en Linux getest en heeft het probleem niet

Dat zeggen ze nu.
RMA's lijken mijns inziens te wijzen op een ernstig probleem waarbij ze er momenteel nog niet uit zijn wat de precieze oorzaak is.

Het kan software zijn (Microcode/kernel code whatever), maar het kan net zo goed een hardware issue (silicon) zijn waarbij een deel van de yields goed lijkt maar onder specifieke stress toestanden toch problemen blijken te geven.

[Aetje]

Hangt er vanaf of het reproduceerbaar is. Zelfde input vanuit dezelfde omstandigheden is crash? -> Software bug, kernel patch of microcode update lost het op. Niet reproduceerbaar maar incidenteel fouten? -> Brakke batch processors, die waarschijnlijk lager geklokt moeten worden om dit te fixen.

Gezien de nogal specifieke omstandigheden waar de fout in optreed vermoed ik een software issue.

[j1b2c3]

Aan gezien het onder Windows niet voor komt , is het een software probleem en niet hardware. Tevens iedereen weet dat Linux + nieuwe hardware altijd experimenteel is en veel problemen kan geven.

[BeosBeing]

Het is een nieuwe architectuur , niet met de focus op Linux maar op Windows machines.

Dat is deel van het probleem. Windows is veel te dominant.

[foppe-jan]

het lijkt nogal gevoelig voor geheugen, impedantie- en voltage (en dus ook llc?) instellingen, en ze zeggen dat ze het ondertussen opgelost hebben of tijdens de QA/binning afvangen. Gevalletje van te veel hardware om te testen in te korte tijd, gegeven dat ze niet langer konden wachten met lancering vanwege geld, enz. Het is zoals het is, maar goed, ze zijn prima bereid om het op te lossen, en zoveel linuxgebruikers (met problemen) zijn er ook weer niet, want veel meer dan 10 mensen heb ik er niet over zien klagen (ook al zijn die 10 mensen erg druk).

[rjmno1]

Ja ik vind het een beetje slordig van amd, maarja het gros van de gebruikers gebruiken toch alleen maar windows.
Ik kan me herinneren vroeger dat er een processor was die rekenfouten maakte.
Was het niet in het begin van de Pentium era?
Zou je die hardware matige fout software matig kunnen oplossen?

[Reactie gewijzigd door rjmno1 op 23 juli 2024 01:39]

[PepijnK]

Ja ik vind het een beetje slordig van amd, maarja het gros van de gebruikers gebruiken toch alleen maar windows.
Ik kan me herinneren vroeger dat er een processor was die rekenfouten maakte.
Was het niet in het begin van de Pentium era?
Zou je die hardware matige fout software matig kunnen oplossen?

Er zijn er toen een aantal geweest waaronder de FDIV bug. Overigens was de FDIV bug niet echt iets waar de gemiddelde gebruiker last van had. F00F was ook zo'n soort bug, waardoor een CPU ging hangen. Cyrix had de coma-bug, die later een work-around heeft gekregen in microcode.

Volgens mij zijn er maar weinig processoren die als je het op die manier gaat bekijken geen Halt & Catch Fire instructie hebben, of een combinatie van dingen waardoor een CPU zichzelf in een onmogelijk loop drukt.

De enige reden waarom iedereen de Pentium FDIV bug kent is dat CNN er mee aan de loop is gegaan en IBM dat als kans heeft gezien om hun eigen 5x85 te pluggen. Niet omdat het iets was waarover de gemiddelde gebruiker hun Pentium 60 ging terugbrengen en Intel miljoenen chips heeft moeten vervangen.

[Reactie gewijzigd door PepijnK op 23 juli 2024 01:39]

[graverobber2]

Het probleem is opgelost in de B1 steppings van Ryzen (dus ook EPYC en Threadripper), dus het lijkt mij eerder hardware gerelateerd

[JackBol]

B1 is de huidige stepping.

[graverobber2]

Ja, maar dit probleem is van voor de B1 stepping

[JackBol]

B1 is de eerste stepping.

[foppe-jan]

ja, lijkt erop dat de eerste batches gevoeliger waren dan wenselijk voor geheugentimings, voltages (vooral vSoC).

[Verwijderd]

Tsjah.. Als iets bijna te mooi om waar te zijn lijkt is dat helaas ook vaak zo.

Begrijp me alsjeblieft niet verkeerd, hulde aan AMD voor het hele Ryzen verhaal, want dat was natuurlijk een behoorlijke stap om te zetten, en het zijn hoe dan ook goeie processoren, en nu is de concurrentie ook weer een beetje wakker geschud, maar hoe langer die dingen bestaan hoe meer naar buiten komt dat AMD toch wel wat steekjes heeft laten vallen, al met al doet Ryzen minder aan de naam dan misschien gehoopt/nodig was, want uiteindelijk is het dus nog steeds een beetje het zelfde verhaal, AMD richt zich op een wat goedkoper segment, doet daardoor concessies, en loopt dan vervolgens wederom tegen de lamp omdat de processoren gewoon nog steeds niet met de concurrentie mee kunnen komen, zelfs nu ze op papier beter & sneller zijn.

Ik hoop van harte dat ze snel met 'Ryzen 2' komen en daarin de verschillende problemen aanpakken, dat Threadripper verhaal word het volgens mij namelijk ook niet, dat is leuk op papier, maar een redelijk bizarre vorm van overkill in de realiteit.

[Verwijderd]

Als ze dit gewoon goed oplossen, dan is iedereen dit over drie maanden vergeten. De Pentium kon ook niet rekenen.

https://en.m.wikipedia.org/wiki/Pentium_FDIV_bug

[Reactie gewijzigd door Verwijderd op 23 juli 2024 01:39]

[Arrigi]

Klinkt alsof je nogal negatief wil zijn. Met Ryzen krijg je mooie bang/buck, op alle CPUs - ongeacht 'klasse' - SMT en een unlocked multiplier.

En nu is er een gevalletje in de marge gevonden waarbij onder zeer specifieke omstandigheden, voor zeer specifieke gebruikers een fout is. Een fout die goed mogelijk opgelost is met een patch voor de kernel van dat specifieke OS.

Gezien alle dingen die fout kunnen gaan op een hypercomplex systeem als een moderne multicore CPU is dit miniem. Er zijn door de jaren andere bugs geweest die vaak ook een minimale impact hadden. Vaak kan er een kernelpatch/driver update voor geschreven worden, soms niet.
Dit is niet uniek voor AMD.

Anders kan je ook iets schrijven over hoe Intel "toch weer een steekje laat vallen" met de onduidelijk heid over de i9s en PCI-E kanalen.. en als je extra features wil, moet je een speciale 'key' kopen en op je moederbord klikken.

[SG]

Skylake is RyZen al voorgegaan met bug. Als mission critical toepassing zit gebruik je geen nieuwe hardware maar bewezen hadware dus hardware wat al lang in gebruik is en wat voor bugs er waren al opgelost zijn. En dat houd dus in dat de naam niks waard is. Zoals common is dat je in software bugs kan verwachten geld dat voor hardware ook.
Houd ook in dat kwa kwaliteit mekaar amper ontlopen.

Voor games is skylake bug niet zo belangrijk
En ik gebruik geen linux laat staan compileren.
Al compileer ik wel in windows.
Threadripper heeft die bug niet waar mijn keuze op valt.

[stewie]

Noem eens 1 concessies dan? Deze bug is waarschijnlijk gewoon software/firmware.. (en ze zijn sneller voor een lagere prijs dan intel, ja de super dure intel is sneller )

[Reactie gewijzigd door stewie op 23 juli 2024 01:39]

[Verwijderd]

Nou, een van de minpunten blijkt gaming, en dat is nou net de markt waar AMD (& Intel) de meeste CPU's aan verschepen, kijk maar eens naar een stuk of 5 vergelijkende game benchmark artikelen, 4 van de 5 'wint' Intel

Een ander probleem is single core performance, helaas is vandaag de dag nog heel veel software simpelweg niet gemaakt voor multi-core setups (hoe gek ook) en dan draait een programma dus maar op 1 core, zo'n programma is dan een stukje minder snel op 1 core van een ryzen dan 1 core van een i7, simpelweg omdat een beetje ryzen 8 cores heeft (tegenover 4 in een beetje i7) en ze dus per stuk minder krachtig hoeven te zijn.

Zo zijn er nog wel meer struikelblokken, video streamen (iets wat ze notabene geadverteerd hebben) schijnt niet lekker te werken bijvoorbeeld, ook weer een vrij pijnlijk punt nu iedere jonge gamer (lees; mogelijke klant) zn geluk wil zoeken met game-streams.

Al die problemen zijn gewoon een leermoment voor AMD, niets meer en niets minder, maar jammer genoeg mag je de historie van een bedrijf of product blijkbaar niet meer aanhalen in reacties, dat is ongewenst...

[stewie]

Wat heeft intel dan te bieden vs de AMD FX-8300/Ryzen 3 voor 90 euro? Of Qua functionele GPU's? (En ja jonge gamers kopen geen APU, maar een FX8300 of hoger, met een losse GPU: Kijk ook ff op youtube )

Oh en als je streaming doet is een FX-8300/Ryzen 3 beter dan een i3 intel, omdat video streaming wel gebruik maakt van meerdere cores, zelfs als de GPU acceleratie daarvoor heeft.

Sorry, wel vet dat je zo'n CPU kunt kopen voor zo'n prijs, helemaal als veel multitaskt, dan is elke dual core i3 helemaal een drol van een chip

[Reactie gewijzigd door stewie op 23 juli 2024 01:39]

[himlims_]

Toch best bijzonder, over algemeen (verleden) werkt AMD-cpus ideaal icm Linux, of werd ondersteuning tijdig ingebouwd. (GPU is heel ander verhaal). Zal vast wel gefixed worden..

What's less clear is how this issue will be fixed, but AMD did have some positive things to relay to us. For starters, the company is going to be working with all of its customers that are affected by this bug to resolve the issue. The fact that there is a potential solution is a very good thing (it could be as simple as altering the system configuration). That leads us to believe a kernel fix will be deployed at some point. Tying into that, AMD has also committed to enhancing its Linux testing going forward, so that bugs like these will be found a lot sooner.

Geldt niet voor de enterprise-EPYC processors en de Ryzen Threadripper, maar dat stond al in de post

//edit
Overigens gaf de Ryzen cpu ook segmentation errors (april/mei) bij gebruik van oa GCC, en ook die zijn gefixed of workaround voor beschikbaar.

[Reactie gewijzigd door himlims_ op 23 juli 2024 01:39]

[simplicidad]

Volgens mij komt het niet enkel voor bij zware compilaties. Ik moet maar gewoon eender iets doen in Ubuntu en de boel freezed. Het probleem is dat het ook compleet random gebeurd, de ene keer na 2 uur en de andere keren na 3 minuten. Soms kan ik zonder problemen OpenCV compileren van scratch, andere keren moet ik gewoon Chrome openen voor een crash.

En ik ben absoluut niet de enige.

Nu nieuwe hardware, nieuwe problemen. Ik heb evenzeer in het verleden problemen gehad met Intel om te weten hoe het spelletje werkt.

[RobinJ1995]

Wel beetje ernstig dit... een processor die het bij bepaalde berekeningen gewoon voor bekeken houdt. Lijkt me dat dit best wel een ernstig gebrek aan testing aangeeft, vooral aangezien het blijkbaar op gewoon om het even welk Linux-systeem gebeurt?

[rickboy333]

Geld dit ook voor Epicy? Als dat zo is heb je kans dat Epicy een rough start krijgt die niet meer ingehaald kan worden.

[Wim-Bart]

Het antwoord staat in het artikel.....

[xorpd]

Ik heb een ander probleem met Ryzen onder Linux, weet iemand hier iets meer over misschien? Het gebeurt niet onder Windows. Zie hier voor een voorbeeld: https://www.reddit.com/r/...oblem_xpost_from_rdebian/

[TWyk]

Niets iets voor de frontpage. Probeer het eens op het forum

[foppe-jan]

zou gewoon ook contact opnemen met hun technische dienst, ze zijn vast bereid om met je mee te denken. Ik hoor wel eens vaker mensen over MCEs en timeouts klagen op het segfault topic op amds forum, maar dat is iig een ander probleem, mogelijk deels gerelateerd aan voltage (en ram timing)-instellingen.

[pbeer]

Ik heb een ander probleem met Ryzen onder Linux, weet iemand hier iets meer over misschien? Het gebeurt niet onder Windows. Zie hier voor een voorbeeld: https://www.reddit.com/r/...oblem_xpost_from_rdebian/

Hier een link naar een gelijkaardig probleem:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1530405
Dit stamt al van voor de release van Ryzen en er zijn mensen met een Intel CPU die hetzelfde probleem hebben. Waarom dan zo snel de conclusie trekken dat het Ryzen-gerelateerd is?

[xorpd]

Dat probleem lijkt erop, ja. Ik kan overigens melden dat het probleem weg is (of significant minder voorkomt, dat kan natuurlijk ook) als SMT uitgeschakeld is. Ik heb overigens niet de conclusie getrokken dat het probleem aan Ryzen ligt, dan zou het probleem zich ook voor doen onder Windows namelijk.

[mutley69]

Da's zoals ASUS die voor een dimm combo op hun lijst die maar niet op 2666MHz ook niet wist te vertellen dat het optrekken van het voltage met 0,05V per keer - je er uiteindelijk wel uit kan geraken - zucht... Daarvoor moet je 't ook op fora lezen!
Support tegenwoordig is een heel heel mager beestje - en we mogen blij zijn dat AMD er al mee bezig is - op hoop van zegen maar zeker?
Ergens stond een verklaring - nl. laat 'm niet automatisch optimaliseren en 't gaat wel goed met gcc. We zien wel - bij de volgende patch zeker?

[mutley69]

Ik heb 't ook zitten - maar eer het crasht moet ik wel een aantal zaken doen die in een normale omgeving zich niet voordoen. Vb. 12 compilaties tegelijkertijd starten van gcc. Zet je SMT uit - dan blijft de bug weg bij mij. Gedurende 2200sec gaat het goed - en dan valt de ene compile lus na de andere uit. Geen kernel crashes niks van dat alles. Op zich is er niet meteen iets waar ik me druk ga om maken - maar er zal wel een reden zijn waarom men een terugroep toestaat. Doordat AMD dat doet - zal ik sneller m'n 2e systeem ook vervangen door een AMD - en m'n laatste intel laptop vliegt er ook uit en wordt ook een Ryzen. Wie support geeft - krijgt m'n centen. Wie zich gedraagd als een despoot - en veroordeeld wordt - zoals Intel - zal moeten hopen dat er geen alternatief meer is... (u doet uiteraard waar u zin in heeft).
Onder zo'n load zal een uitzonderlijke situatie ontstaan zeker? Waarom het vanaf week 25 dan weer wel ok zal zijn - dat weet AMD.
Ik ga alvast contact opnemen met AMD voor een RMA.