Forum Datorkomponenter Processorer, moderkort och minnen AMD Tråd Inlägg

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

1 2
Skriv svar
Permalänk
Medlem
●

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.

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Medlem ★
●

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.

Visa signatur

Ryzen 9 5950X, 32GB 3600MHz CL16, SN850 500GB SN750 2TB, B550 ROG, 3090 24 GB
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, 1080 ti, 2080 ti, 3090 AMD Radeon 9200, 4850 CF, 6950@70, 6870 CF, 7850 CF, R9 390, R9 Nano, Vega 64, RX 6800 XT
Lista beg. priser GPUer ESD for dummies

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

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.

Visa signatur

För övrigt anser jag att tobak ska förbjudas.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

@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.

Visa signatur

| Fractal Design Define R5| Asrock X399 Fatal1ty| Threadripper 1950X| Noctua NH-U14S TR4-SP3| Corsair Vengeance LPX 8x16GB 3200 C16| be quiet! Straight Power 11 Platinum 1000W| ASUS RTX 3080 10GB Strix| LG OLED 4k 42" C2| Debian Sid| KDE 5.x|

Redigera
Citera flera Citera
Permalänk
Medlem
●

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"....

Redigera
Citera flera Citera
Permalänk
Medlem
●

@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 :/

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

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.

Redigera
Citera flera Citera
Permalänk
Medlem
●

@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?

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●

@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.

Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

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.

Redigera
Citera flera Citera
Permalänk
Medlem
●

@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...

Redigera
Citera flera Citera
Permalänk
Medlem
●
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...

Gå till inlägget

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

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Datavetare ★
●

@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".

Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Medlem
●

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.

Redigera
Citera flera Citera
Permalänk
Medlem
●

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

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

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.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

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

Redigera
Citera flera Citera
Permalänk
Medlem
●

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..

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av ronnylov:

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

Gå till inlägget

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"

Visa signatur

5800x -- 32Gb DDR4@3600 -- 3080Ti -- 500Gb M2+1Tb M2 +2x1Tb sata SSD

Redigera
Citera flera Citera
Permalänk
Hjälpsam ★
●

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

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Redigera
Citera flera Citera
Permalänk
Medlem
●

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?

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●

@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.

Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

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

Visa signatur

Huvudriggen är en Gigabyte Aorus Xtreme | 128gb DDR5 6000 | Ryzen 7950X | 3080Ti
Utöver det är det för många datorer, boxar och servar för att lista :P

Redigera
Citera flera Citera
Permalänk
Hjälpsam ★
●
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.

Gå till inlägget

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.

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Precis köpt Ryzen 7 1700 batch UA 1732SUS från Inet

Ska precis bygga min första Ryzen ITX build och grävde runt lite angående segmentationsfelet i olika forum när jag först fick hem en Ryzen 7 1700 UA 1716PGT och insåg att den var utpekad som en batch med problemet(eller iaf vanligt förekommande). Det verkar iaf som att batcher från vecka 25 och nyare ska vara fria från denna bugg, så kändes ju inte bra med en från vecka 16!

Frågade runt hos olika leverantörer i Sverige och Danmark och fick till slut svar från Inet att de hade nya batcher från AMD. Beställde på vinst och förlust och fick hem en Ryzen 7 1700 batch UA 1732SUS idag, win!

Skickades från m.sweclockers.com

Visa signatur

Ryzen 7 5800X3D || Powercolor AMD Radeon RX 6800 16Gb || G.Skill Flare X 16GB 3200MHz CL14 || Gigabyte B550I Aorus Pro AX || LG 27GL850 QHD IPS 144 Hz || Samsung SSD 970 EVO Plus 1TB || Samsung SSD 960 EVO 250GB || Corsair SF600 || Louqe Ghost S1 Limestone || 2xMedium Tophat med 2xNF-F12 + 2xNF-A12x25 || Noctua NH-L12

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Äsch jag får segmenteringsfel vid vanlig kompilering i Arch Linux nu efter jag kom på att köra med 16 trådar. Har inte kört kill_ryzen men jag verkar alltså ha buggen vid normal användning. Kompilerade igen och felet kom inte och en tredje gång så kom felet igen.

Ryzen 7 1700 vecka 23

Suck...

Redigera
Citera flera Citera
Permalänk
Medlem
●

faen-var tidig ute med att köpa min ryzen som på ett senare skede ska användas vid kompilering under linux. Räknar med att buggen finns hos mig med. Är RMA-förfarandet omständligt?Tycker att alla tidiga köpare borde erbjudas byte automatiskt- har inte tid att köra kill-ryzen scriptet/testa med detta än.

Visa signatur

Ryzen 7 1700x@Corsair Vengeance, 16 GB(2x8Gb) DDR4, 3200 Mhz, CL16@Corsair h110i@Asus STRIX Radeon RX480 8GB DDR5 Strix gaming OC@Asus Prime X370-Pro@Fractal Design Integra M 550W

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av swedwalker:

faen-var tidig ute med att köpa min ryzen som på ett senare skede ska användas vid kompilering under linux. Räknar med att buggen finns hos mig med. Är RMA-förfarandet omständligt?Tycker att alla tidiga köpare borde erbjudas byte automatiskt- har inte tid att köra kill-ryzen scriptet/testa med detta än.

Gå till inlägget

För mig tog det runt 2 till 3 veckor innan jag fått processorn till dörren, detta inkluderar ledtider då de ofta svarar två till tre dagar efter att du svarat på deras mail. De kommer att be dig testa olika inställningar i bios, olika SoC och CPU voltages. Efter detta kommer de be dig skicka tillbaka din processor och motta en ny. Om du ber snällt så kan de eventuellt skicka ut en ny redan innan du skickat din, det gjorde de åt mig då jag har min i en server och inte ville ha downtime. Jag kan tipsa om att ringa DHL när du ska skicka tillbaka den, din lokala DHL service point lär se ut som frågetecken när du ger dem AMDs prepaid account number som du får av dem vid godkänd retur.

Skickades från m.sweclockers.com

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Jag har reproducerat felet både genom daglig användning och kill_ryzen scriptet på 4 CPUer. Jag trodde buggen skulle vara ovanlig. De testade processorerna är 3st 1700x och en st 1800x. Två av 1700x processorerna är vecka 41. 1800x var vecka 18 dock.

/Knight

EDIT: Daglig användning = kompilera debian kernel i Linux Mint med 16 trådar och kompilera Yocto i Linux Mint med 16 trådar. Jag kör minnen enligt dokumentation från Gigabyte.

Visa signatur

Idag kom Athlon64

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Knightmare:

Jag har reproducerat felet både genom daglig användning och kill_ryzen scriptet på 4 CPUer. Jag trodde buggen skulle vara ovanlig. De testade processorerna är 3st 1700x och en st 1800x. Två av 1700x processorerna är vecka 41. 1800x var vecka 18 dock.

/Knight

EDIT: Daglig användning = kompilera debian kernel i Linux Mint med 16 trådar och kompilera Yocto i Linux Mint med 16 trådar. Jag kör minnen enligt dokumentation från Gigabyte.

Gå till inlägget

Det finns andra orsaker till att man kan få segfault, men samtidigt har jag läst om ett fåtal exemplar efter vecka 25 som ändå haft detta problem, men det ska vara extremt ovanligt.

I princip alla Ryzen före vecka 25 har detta fel (80 - 100%), men få märker av det eftersom det främst är vid kompilering i Linux det märks, och det inte är något de flesta användare sysslar med. AMD har därför valt att ligga lågt och bara byta ut processorer på begäran istället för att återkalla en stor mängd produkter.

Visa signatur

Ryzen 7 3800X, Asus Prime X370 Pro, 32 GB LPX 3600, Gainward RTX 3060 Ti Ghost, 7 TB SSD + 4 TB HDD

Redigera
Citera flera Citera
1 2
Skriv svar
Senaste nyheterna
Hårdvara
Mjukvara
Övrigt
Nytt i forumet
Datorkomponenter
System
Ljud, bild och kommunikation
Spel och mjukvara