Extrém terhelésre hibákba futnak Linux alatt az egyes asztali Ryzen processzorok

Az AMD hivatalosan is megerősítette a probléma létezétést, de a Threadripper és az EPYC CPU-kkal nem jön elő a gond, ahogy Windows alatt sem.

Egy ideje már téma linuxos körökben, hogy az asztali Ryzen processzorok extrém terhelésre, ezen belül is számos, párhuzamosan futtatott fordítás alatt szegmentálási hibát generálhatnak. Ezt azért volt nehéz korábban tesztelni, mert igen ritka jelenségről van szó, amelyet nem is mindenkinek sikerül reprodukálni.

A hibakeresés az ezen a GitHub oldalon megosztott szkripttel gyorsult fel, ami az Ubuntu 17.04-hez készült. Ennek a futtatása 16 GB-nál több memóriát igényel, de a feladat, amit végrehajt, szinte mindig szegmentálási hibát generál azok számára, akik korábban már tapasztalták ezt a problémát, vagyis jóval egyszerűbbé vált a tesztelés. Persze maga a feladat annyira erős terhelés, hogy hajlamos más, nem Ryzen processzorokon is ilyen jellegű hibát dobni, ami miatt nem igazán lehetett tudni, hogy mi a gond, így egyesek a GCC-t hibáztatták, mások a Linuxot, tehát nehéz volt bármi érdemlegeset kideríteni.

A fenti káosznak végre vége, ugyanis az AMD jelezte, hogy sikerül reprodukálniuk az érintett felhasználók által tapasztalt problémát. A vállalat közleménye szerint a gond a Linux felhasználókat érinti, de nem kizárt, hogy más Unix-alapú környezetben is előjön, megemlítve a FreeBSD-t, bár utóbbi operációs rendszeren a panaszok nagyságrendekkel ritkábbak, illetve esetlegesen más hibákra is visszavezethetők. A cég azt is elmondta, hogy a Ryzen Threadripper és EPYC CPU-kkal a hiba nem jön elő, illetve natív Windows környezetben sem sikerült még reprodukálni.

Az eddigi tesztek alapján az is kiderült, hogy a hiba nem köthető bizonyos alaplapokhoz, illetve -gyártókhoz sem, ami azért lényeges, mert a hibátlanul működő Ryzen konfigurációk miatt korábban többen is az alaplapokat tették felelőssé. Ugyanakkor ma már biztos, hogy ez nem így van, mivel a felhasználók próbálgatják a jelenséget, és volt olyan, szegmentálási hibát nem generáló Ryzen asztali processzor, amely több alaplapban is hibátlan maradt.

Az AMD a hibázó CPU-kat korai Ryzen modellekként jellemzi, ami arra utal, hogy a probléma nem érint minden terméket, és a felhasználók visszajelzései alapján is ez a helyzet, mivel van akinek a konfigurációja hibázik, és van akinek nem. Ennél érdekesebb, hogy a cég szóvivője a hiba leírásában utalást tesz a környezeti hőmérsékletre, illetve a nem ideális környezeti viszonyokra, ami arra enged következtetni, hogy ennek is köze lehet a gondokhoz. Bár a konkrét probléma még nem derült ki, de az eddigi adatok alapján nem kizárható, hogy a hitelesítési teszt lehet a bűnös, ugyanis egy processzort a dobozolása előtt egy komplett tesztsorral ellenőriznek, ekkor határozzák meg a lapka paramétereit is. Ugyanakkor az új termékeknél ez a tesztsor nem mindig olyan robusztus, mint a korábbi modelleknél, mivel új architektúráról van szó. Emiatt előfordulhat, hogy az adott modell hitelesítésénél a tesztek nem fednek le minden eshetőséget, így esetlegesen olyan paraméterezést kaphat egy lapka, amelyet bizonyos körülmény mellett nem bír el. A "korai Ryzen modellek" jelző is vonatkozhat erre, mivel lehet, hogy az AMD ezt már korrigálta, viszont a részletekbe nem akarják beavatni a világot.

A hitelesítési tesztre vonatkozó elmélet rengeteg dologra választ ad. Például arra is, hogy két ugyanolyan processzor az egyik felhasználónál miért jó, míg a másiknál miért rossz, feltéve persze, hogy tényleg nincs köze a hibához az alaplapoknak. De az sem kizárt, hogy más probléma van a háttérben. A lényeg annyi, hogy az AMD várja a Linuxot használó, fenti probléma által érintett vásárlók jelentkezését, akik az alábbi oldalon kereshetik fel a céget. A vállalat azt is elmondta, hogy a jövőben több Linux tesztet fognak végezni az érkező processzoraikon.

A javítás szempontjából egyelőre még nem lehet pontosan látni. Egyes felhasználók szerint a FreeBSD már kapott egy olyan frissítést, ami részben kezeli a problémát, és hasonlót kaphat a Linux is. Ha az operációs rendszer oldalán korrigálható a hiba, akkor valószínűleg nem lesz mikrokódfrissítés, de nem kizárt, hogy végül erre is szükség lehet.

  • Kapcsolódó cégek:
  • AMD

Azóta történt

Előzmények

Hirdetés