AMD bekräftar problem med Ryzen som resulterar i segmentationsfel i Linux

Trädvy Permalänk
Medlem
Plats
Motala
Registrerad
Dec 2010

AMD bekräftar problem med Ryzen som resulterar i segmentationsfel i Linux

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

https://community.amd.com/thread/215773

Tankar? Jag körde detta test och får tyvärr detta problem i min Ryzen 1700X server.

För mig personligen är det oroväckande då jag är utvecklare till yrke och även om jag inte stött på problemet i vardagen ännu så är det ju inte så kul att veta att kompilering kan få hela systemet att bli instabilt.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Aug 2007

Det är såklart tråkigt. Som du ser i tråden får de med problem skicka in sina CPUer och får nya.
Så det är bara att byta ut den om du kompilerar mycket parallellt.

Nytt bygge: Ryzen och ev. Vega
ASUS Sabertooth P67, Intel 2600K@4.7GHz, 2x8GB DDR3 2133MHz, R9 390
Har haft dessa GPUer: Tseng ET6000, Matrox M3D, 3DFX Voodoo 1-3, nVidia Riva 128, TNT, TNT2, Geforce 256 SDR+DDR, Geforce 2mx, 3, GT 8600m, GTX460 SLI, GTX580, GTX670 SLI, AMD Radeon 9200, 4850 CF, 6950@70, 6870 CF, 7850 CF
Lista beg. priser GPUer ESD for dummies

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Aug 2010

Mm. I tråden ser man några användare av distributionen Gentoo - som distribueras som källkod som kompileras på maskinen det ska installeras på. Problemet uppstår tydligen också även om man kör Linux virtualiserat under en Windows-värd.

Att det drabbar just Linux-användare är tydligen pga att Linux oftare använder högre virtuella minnesadresser än Windows.
Killen som isolerade felet redan April är dock inte Linux-användare utan utvecklar kärnan i Dragonfly BSD Unix.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jan 2007

@Yoshman har besvarat och förklarat det här tidigare i en annan tråd i anslutning till när det upptäcktes, för tre veckor sedan.

Även här #16944053

Det går att forcera fram men är tillräckligt ovanligt för att gemene man inte drabbas.

Läs Yoshmans förklaring.

|FD Define R5|P35-DQ6|Q6600|Ultra-120eXt|Noctua NF-S12-1200|OCZ ZX 1000W|4x2GB Corsair667MHz |HD 4870|Samsung TA24-550|Win 10/Debian Sid KDE 5|¤|Gigabyte GZ-XX1CA-SNS|Asus P8P67-B3|2500K|OCZ GXS 850W|2x4GB Corsair Vengeance|GeForce GTX670|Philips 27"|Debian Sid KDE 5|

Trädvy Permalänk
Medlem
Registrerad
Dec 2016

Hej

Eller så kan du använda fixet som togs fram för att kringgå detta problem.

(lösning var tror jag att sänka userspace adr en sida i kerneln så att inte tracecachen kan klättra över gränsen mellan userspace och jumptablen. Finns massor att läsa på forum om linux. Främst de distar som levereras okompilerade, tex Gentoo mm. Tror inte alla distar är fixade eller att ett generellt fix finns ute än.)

Jag hade länkar till lösningen tidigare men kastat dessa då jag inte kompilerar. Eget nördigt intresse att kolla upp sådana här "fel"....

Trädvy Permalänk
Medlem
Plats
Motala
Registrerad
Dec 2010

@sAAb: Tack för referensen, intressant läsning.

Även om problemet går att kringgå så är det viktiga för mig att det är ett hårdvaurfel i CPUn vilket jag inte accepterar oavsett om jag aldrig någonsin kommer märka det. Jag kompilerar sällan på alla trådar i och med att min ryzen sitter i en KVM server där ingen VM har alla trådar tillgängliga. Jag är för närvarande i en felsökningsprocess med AMDs support. De bad mig testa lite olika vcore precis som de frågat andra på AMD forumet om. De nämnde att mitt RAM inte är med i qvl listan i ett mail utan att diskutera det vidare vilket jag hoppas inte påverkar processen.

Ni som har ryzen, testa gärna efter felet och om ni kan, skriv upp er serie av CPU på AMDs forum (d.v.s den kod som står fysiskt på processorns lock) så att det blir lättare att lokalisera vilka serier som lider av detta.

Det jag är mest rädd för är att min server kommer ligga nere i flera veckor :/

Trädvy Permalänk
Medlem
Plats
Borås
Registrerad
Okt 2002

Verkar som problemet är vanligare på Ryzen tillverkade före vecka 25.
https://community.amd.com/thread/215773?start=997&tstart=0
https://www.phoronix.com/forums/forum/phoronix/general-discus...

Ska kolla vad det står för vecka på min R7 1700 som jag fick häromveckan (inte installerat datorn ännu). Ska köra Linux med den var det tänkt. Om jag får problem med den är ju detta något att ha i bakhuvudet.

Trädvy Permalänk
Medlem
Registrerad
Dec 2016

@arebokert

Inget riktigt hårdvarufel detta, snarare ett timingsfel som uppkommer väldigt sällan BARA när sista 4k userspace adr sidan används samtidigt som vektorer i jumptabellen har alla utom en bit samma. Därav att man måste kompilera som bara den eller köra "kill_ryzen" skript etc. som en galning. Det är inte garanterat då heller och en anledning att tex spänning till chip och SMT kan påverka, medan att slå av uopcachen verkligen påverkar om man har ett sådant MB som tillåter detta.

Vi får se vad AMD gör åt detta. Kan ev fixas med en ny AGESA eller så finns i alla fall Hotfixen för linux (att sänka userspace).

Kolla om din linux dist har denna hotfix och du kan/vill kompilera om den?

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011

@Dack3: problemet du beskriver fanns endast i FreeBSD och DragonflyBSD. Linux och Windows var aldrig påverkade. Detta fel är ack:at av AMD och man är överens om en workaround som numera är implementerad i båda *BSD varianterna.

Segfault är ett annat problem (initialt visste man dock inte om det var samma problem) och det felet är inte på något sätt specifikt till vare sig GCC eller Linux. Kollar man t.ex. Gentoo tråden är det ofta andra saker än just GCC-processen som kraschar när det händer, däremot är just kompilering med GCC där alla kärnor jobbar en katalysator för att trigga det hela.

Men samma problem har återskapats med LLVM/Clang, det har återskapats på BSD-varianter och även på Windows, där genom att använda GCC via LSW (Linux Subsystem on Windows 10). Notera att LSW inte på något sätt är virtualisering, man kör fortfarande med Windows-kärnan.

Däremot uppträder felet långt mer sällan på andra kombinationer är just Linux+GCC+ASLR (Address Space Layout Randomization) påslaget.

Av mycket att döma är felet endera avhjälpt i senare revisioner alt. så är det bara långt svårare att trigga. Det faktum att AMD ännu inte sagt något officiellt om detta pekar på att man inte riktigt förstår mekanismen än.

Detta är ett uppenbart race-condition någonstans i HW, tyvärr är det lite av worst-case när det kommer till svårighetsgrad att hitta orsaken (och ett race kan aldrig deklareras som "fixat" innan man helt kan förklara varför det uppstod tidigare, att det verkar sluta krascha är inget bevis alls). Tog ju Intel flera år innan man hittade problemet med TSX (tog till att börja med ~2 år innan man ens insåg att det fanns en bug), tog nästan ett år innan man hittade det race Skylake hade ihop med vissa specifika laster och HyperThreading.

För Windows-användare verkar detta i praktiken vara ett icke-problem. På Linux påverkar det egentligt bara de som kör Gentoo eller motsvarande samt de som använder sin Linux som utvecklingsmaskin.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Plats
Borås
Registrerad
Okt 2002

Jaha min "nya" Ryzen 7 1700 CPU hade tillverkningsvecka 23 så den blev tyvärr inte nyare än vecka 25. Då är den antagligen påverkad av denna bugg. Jag kör ju Arch Linux och där kompilerar jag en del från AUR men det är klart inte någon huvudsyssla så frågan är om jag ens kommer märka av det.

Trädvy Permalänk
Medlem
Registrerad
Dec 2016

@Yoshman

Vet om LLVM/Clang och GCC/LSW och tror att "personligen" att detta hänger ihop. Såg en kille som kollat upp alla de Segfault som han fått när han testade under linux. Enligt honom var det endast en bit i den virtuella adressen som skiljde mellan det som det offset i berört register som var mot jumptablen.

Race-condition är troligt eller nått liknande som att inte hinna låsa/uppdatera ett register innan uopcachen svarar med ett "korrekt" värde men som inte får användas pga inte tillhör tråden som kör!?

AMD byter ju trots allt ut CPUn om du pratar med dom. Vi får se vad de kommer fram till om/när de hittar felet.

Dock tycker jag det verkar mycket svårtriggat då en 16 GCC måste hålla på ett tag för att få felet alls. Partiet som är fel måste mao hamras en hel del innan "rätt" värden hamnar i fel läge för att få segfaulten. Är det en på 10000 passager som kraschar äns...??? (vet ej själv men inte heller den självmodifierande koden i "kill_ryzen" lyckas ofta trots att den snurrar runt bra fortare än vad GCC gör....)

Jag vill också veta vad felet är....hehe, bara för att...

Trädvy Permalänk
Medlem
Plats
Motala
Registrerad
Dec 2010
Skrivet av Dack3:

@Yoshman

Vet om LLVM/Clang och GCC/LSW och tror att "personligen" att detta hänger ihop. Såg en kille som kollat upp alla de Segfault som han fått när han testade under linux. Enligt honom var det endast en bit i den virtuella adressen som skiljde mellan det som det offset i berört register som var mot jumptablen.

Race-condition är troligt eller nått liknande som att inte hinna låsa/uppdatera ett register innan uopcachen svarar med ett "korrekt" värde men som inte får användas pga inte tillhör tråden som kör!?

AMD byter ju trots allt ut CPUn om du pratar med dom. Vi får se vad de kommer fram till om/när de hittar felet.

Dock tycker jag det verkar mycket svårtriggat då en 16 GCC måste hålla på ett tag för att få felet alls. Partiet som är fel måste mao hamras en hel del innan "rätt" värden hamnar i fel läge för att få segfaulten. Är det en på 10000 passager som kraschar äns...??? (vet ej själv men inte heller den självmodifierande koden i "kill_ryzen" lyckas ofta trots att den snurrar runt bra fortare än vad GCC gör....)

Jag vill också veta vad felet är....hehe, bara för att...

Angående hur lång tid det tar så kan jag i alla fall nämna att det alltid sker på runt 100 sekunder på min setup.

Med tanke på att felet är omöjligt att replikera med testade metoder på de CPUer AMD skickar ut som uppföljning så borde väl felet vara lokaliserat? Alla CPUer tillverkade efter ett datum verkar ju inte ha felet så AMD borde ju kunna se vad som förändrades i tillverkningsprocessen efter det datumet.

Skickades från m.sweclockers.com

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011

@Dack3: ah, det informationen du hittar är kanske ändå relaterad till segfault problemet då.

Det man hittade som vad *BSD specifikt triggades också av t.ex. intensiv kompilering, där spårande man det till att instruktionen "iret" (return from interrupt service routine) kunde hänga om den andra CPU-tråden i samma fysiska kärna var fullt lastad och virtuella adressen för anropsstacken för IRQ-rutinen var mappad till sista 4k av det virtuella adressutrymmet (vilket var fallet på FreeBSD och DragonflyBSD men inte på Linux och Windows).

Fixen där blev då rätt uppenbar, se till att bara markera sista 4k av virtuella adressrymden som "använd inte".

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Registrerad
Sep 2017

Finns det någon butik som säljer nyare än UA 1725? Det nyaste jag hittat efter att ha gått runt till webhallen/inet är UA 1718 (vecka 18). Känns lite drygt att köpa en och direkt behöva gå igenom AMDs process med att kolla vcore/luftflöde i låda och sedan göra en RMA.

Trädvy Permalänk
Medlem
Plats
Motala
Registrerad
Dec 2010

Jag kan tillägga att nu efter 25 dagar av kontakt och testande med AMDs support har jag fått en ny CPU, satt i den och får inte längre detta fel. Jag hade en UA1709PGT och har nu fått en UA1728SUS. Det ska nämnas att AMDs support var helt underbara och skickade en ny CPU i förväg på begäran för att minska min downtime. Nu när jag fått den ska jag skicka tillbaka den gamla

Trädvy Permalänk
Medlem
Plats
Borås
Registrerad
Okt 2002

Ni som har fått ny CPU kanske kan använda kill-ryzen scriptet för att testa om den är stabil även vid överklockning. Tänker eftersom AMD är så noga att kolla att det inte har med kylning eller vcore att göra så borde testen vara känslig för sådant. Alltså ett perfekt verktyg att kolla stabilitet vid överklockning

Själv har jag inte kört testen ännu på min R7 1700 UA1723 men har inte märkt några problem heller vid normal användning i Arch Linux. Känner inte att jag måste få den utbytt för ett problem som inte påverkar mig i praktiken. Men i och för sig kan det väl vara kul att veta om man har buggen eller inte.

Trädvy Permalänk
Medlem
Plats
Borås
Registrerad
Okt 2002

Det ryktas om att AGESA 1.0.0.6b bios-uppdatering ska kunna hjälpa mot denna bugg.
http://www.phoronix.com/scan.php?page=news_item&px=AGESA-1.0....

Och så har någon gjort ett kill-ryzen-win script som påstås kunna trigga buggen även i Windows.
https://github.com/corngood/kill-ryzen-win

Trädvy Permalänk
Medlem
Registrerad
Sep 2017

Jag har lyckats trigga buggen i windows subsystem for linux med kill_ryzen iallafall. Ska vänta på den där agesa-uppdateringen sedan blir det nog att starta rma-förfarandet..

Trädvy Permalänk
Medlem
Plats
!
Registrerad
Dec 2007
Skrivet av ronnylov:

Verkar som problemet är vanligare på Ryzen tillverkade före vecka 25.

jupp, verkar så. går man igenom hela processen med AMD så får man en ny processor. Har nu startat scriptet...
för Arch : (pacman -S base-devel förutsatt) rad 26 exit 1 ersätts med echo "bla"

Gigabyte AX370 Gaming k3, Ryzen 1600, GSkill DDR4 16Gb, 500Gb Samsung Evo M2, Nvidia MSI 1070, 1Tb Sata SSD

Trädvy Permalänk
Hjälpsam
Plats
Karlskoga
Registrerad
Jan 2007

Har någon testat köra skriptet på Intel?
https://www.phoronix.com/forums/forum/hardware/processors-mem...

AMD Ryzen 7 1700 | https://valid.x86.fr/bvpyq6 | Stockkylaren | Bitfenix Whisper M 750W | Corsair 600T Graphite vit.
AMD FX8350 | https://valid.x86.fr/0q5pkm | Cooler Master V 700W | 32 GB ECC-Minnen.
HTPC | https://valid.x86.fr/ez1zxw |

Trädvy Permalänk
Medlem
Registrerad
Sep 2017

Har vi fått någon uppdatering om det här? Finns problemet fortfarande kvar? Vet vi vilka processorer som var påverkade? Om jag t.ex. skulle köpa en R5 1600 från Inet nu, är det garanterat att jag inte får en defekt enhet?

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011

@Burkmannen: Felet ska vara avhjälpt i modeller tillverkade efter vecka 25, eventuellt finns nu även en fungerande patch för tidigare modeller (men tycker det verkar vara lite blandade bud på det).

Köpte en R5-1600 för ett tag sedan, det på Webhallen. Den var rätt färsk krets, tillverkad v30. Kör Linux, använder datorn för div. programmeringsprylar och har så här långt inte märkt några problem alls (det trots en Nvidia GPU och att jag främst lekt med CUDA-programmering så här långt ).

Har inte och tänker inte överklocka, kör RAM på avsedd hastighet.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Plats
Karlskrona
Registrerad
Aug 2009

Vet någon om detta påverkar/påverkade Threadripper också och i så fall vilken stepping som inte har problemet?

Asus Z97 Pro Gamer | 32gb ram DDR3 2400MHz | i7 4790k | 2 x R9 390
Asrock P67 Extreme4 rev3 | 16gb DDR3 2400MHz | i7 2600K | R9 290
En massa bärbara, servrar, RPi's och andra boxar

Trädvy Permalänk
Hjälpsam
Plats
Karlskoga
Registrerad
Jan 2007
Skrivet av Yoshman:

@Burkmannen: Felet ska vara avhjälpt i modeller tillverkade efter vecka 25, eventuellt finns nu även en fungerande patch för tidigare modeller (men tycker det verkar vara lite blandade bud på det).

Köpte en R5-1600 för ett tag sedan, det på Webhallen. Den var rätt färsk krets, tillverkad v30. Kör Linux, använder datorn för div. programmeringsprylar och har så här långt inte märkt några problem alls (det trots en Nvidia GPU och att jag främst lekt med CUDA-programmering så här långt ).

Har inte och tänker inte överklocka, kör RAM på avsedd hastighet.

Visste att även du skulle hitta ljuset.
Apropå att inte överklocka, märkte jag att min CPU i bland kommer upp i 3750 MHz oklockat.
Så singeltrådat tjänar man inte så mycket, på att överklocka.

AMD Ryzen 7 1700 | https://valid.x86.fr/bvpyq6 | Stockkylaren | Bitfenix Whisper M 750W | Corsair 600T Graphite vit.
AMD FX8350 | https://valid.x86.fr/0q5pkm | Cooler Master V 700W | 32 GB ECC-Minnen.
HTPC | https://valid.x86.fr/ez1zxw |