Problémák az AMD Ryzen processzorral Linux alatt

Hardver

AMD Ryzen tulajdonos Linux felhasználóktól nagyjából április eleje óta megmagyarázhatatlan segfault-okról gyűlnek hibajelentések. A közös pont, hogy mindannyian gcc-vel sok párhuzamos szálon végzett fordítás közben találkoznak a hibajelenséggel, ami leginkább egy bash process-t talál meg. Más módon eddig nem sikerült reprodukálni, az érintett gépek egyéb tesztelési módszerekkel teljesen stabilnak tűnnek.

Nem meglepő módon elsősorban Gentoo felhasználók találkoznak a hibával, így a legtöbb tapasztalat eddig ebben a Gentoo fórumtémában gyűlt össze.

További információ található az AMD community fórumtémájában. Eszerint számos felhasználó már nyitott hibajegyet az AMD fele.

Eddig az AMD hivatalosan nem erősítette meg a hibát.

A felhasználók által tapasztalt tipikus segfault hiba így néz ki:

sh[5627]: segfault at 34 ip 0000000000406215 sp 00007ffdadd984c8 error 6 in bash[400000+a8000]
sh[15390]: segfault at e ip 0000000000406215 sp 00007ffc1c9a0d78 error 6 in bash[400000+a8000]
sh[19903]: segfault at 8 ip 0000000000406215 sp 00007ffd970f79c8 error 6 in bash[400000+a8000]

Jelen pillanatban nincs ismert workaround, ami mindenkinél megoldotta volna a problémát. Egyesek eredményt értek el a következőkkel, míg mások csak a hiba gyakoriságának változásáról számoltak be:

  • SMT (többszálú végrehajtás) letiltása, ezzel logikai CPU-k száma megfeleződik
  • uOP (mikroművelet) cache letiltása - csak kevés alaplap BIOS-ában lehetséges
  • LLC (load line calibration - terhelésfüggő tápfeszültség szabályozás) paraméter állítása
  • Kernel ASLR (memória címtartomány randomizáció) letiltása: echo 0 >/proc/sys/kernel/randomize_va_space

A hibakeresést nagyban nehezíti, hogy a tapasztalatok szerint egyes alaplapok beépített "intelligens" overclocking funkciókkal rendelkeznek, ami - részben hibás megvalósítás miatt - a felhasználó tudtán kívül is aktív lehet, és önmagában képes stabilitási problémákat okozni, ami könnyen összekeverhető a fenti hibajelenséggel.

További érdekesség, hogy a hibát a gépre natívan telepített Windows 10 felett VMware virtuális gépben futó Ubuntu-n is sikerült reprodukálni.

További linkek:
Phoronix beszámolója
Goggle docs táblázat, amiben összegszik az eddig érintett konfigurációkat

( trey | 2017. 06. 06., k – 13:25 )

Nem tudom, hogy minek a baja, az AMD-é vagy az AMD kisebb piaci részesedése miatti kevesebb figyelemé, teszteléséé (akár Linux, akár gcc oldalon), de nem is érdekel. Csak az Intel.

#lettheflamebegin

--
trey @ gépház

Hát ha nem is szökik egekbe, de mondjuk 5 éven keresztül ugyanannyiért szinte ugyanazt adják el. Lásd az elmúlt 5 évet...

Valahol árulkodó, hogy az Intelnél házon belül:
- LCC - low core count néven fut a 10 magos IC
- HCC - high core count néven fut a 18 magos
- XCC - extreme core count néven fut a 22 magos

Ehhez képest hány magos is az i7-7700? És vajon hogy hívhatják házon belül az i3-ak alapját adó 2 magos szilíciumot...

---
Régóta vágyok én, az androidok mezonkincsére már!

De legalabb sokkal kevesebbet fogyaszt ;-)

A regi idokben ~3 ev mulva ketszer
jobb procit vehettel, ugyan azon a penzen, ennek vege.

Most is megveheted, csak kb. 2x annyiba is kerul.

A legtobb desktop user, nem tud mit kezdeni 8+ core-al,
per core meg nem lehet sokkal gyorsabb.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

per core meg nem lehet sokkal gyorsabb.
Bár nemhivatalosan hasonló véleményen vagyok, de ezt valójában viszonylag nehéz megítélni. Nem tudod egyértelműen eldönteni, hogy tényleg az IPC elvi maximuma közelében vagyunk-e, vagy az Intel versenytárs híján egyszerűen elvonta az erőforrásokat a mikroarchitektúra fejlesztéstől, és csak a teljesen kockázatmentes, minimális de garantált előnyöket hozó változásokat lépte meg.

A legtobb desktop user, nem tud mit kezdeni 8+ core-al
Na ezért volt a piacra nagyon káros, amit az Intel művelt. Amíg ugyanis a szoftveres cégek azt látják, hogy mobil vonalon i3-i5-i7, desktop vonalon i3-i5 (vagyis a felhasználói bázis talán 80%-a) mind-mind 4 threades, és ez előreláthatóan jó darabig nem is fog változni, akkor kénytelenek erre optimalizálni. Így a felhasználó (pár speciálisabb alkalmazástól eltekintve) tényleg nem fog tudni mit kezdeni több maggal, a kör pedig bezárult. Persze az Intelnek ez egy kényelmes helyzet volt, mert manapság sok magot bárki tud csinálni (lásd telefonokban előforduló 8 magos ARM), de magonként nagy IPC-t csak az Intel.
---
Régóta vágyok én, az androidok mezonkincsére már!

Miert nem? Miert jo csakazintel?

Az elmult ~20 evben eleg vegyesvagott volt a felhozatalom, nyilvan diakkent arerzekeny voltam. Most csereltem le az 5 eves inteles gepemet egy amds konfigra. Soha nem volt bajom egyik gyartoval sem, de az AMD valamiert mindig is szimpatikus volt, ne kerdezd miert. Azonban nalam soha nem ment el ilyen hitvallasi melysegekbe a dolog. Azt vettem, amire volt penzem, meg ami eppen jobbnak tunt.

Nekem ez a csakazintel, csakazamd olyan, mint amikor Ver Istvan hajtogatja a csakafotobolt, mert csak azzal lehet kepet szerkeszteni, es kulonben is a Gimp, meg a Linugz az szar, mert az nem olyan, es ott nem lehet. Es persze mindezt ugy, hogy massal nem is tudja osszehasonlitani, mert soha nem is hasznalta a masik rendszert...
Lehet picit eros: de mikor is hasznaltal utoljara amds konfigot? Jol sejtem, hogy kb. soha? Mintha derengene, hogy kb. ugyanez volt anno a telefon temakoreben... :)

Tavaly az Intel Museum-ban jártan Santa Clara-ban. Külön kíváncsi voltam, hogy az Itanium-ot hogyan illesztik be a tárlatba. Jól eldugták, de aki figyelt azért észrevette - analitikai eszközökkel nyomokban kimutatható maradt.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

ON: Poén mikor valaki beáll konzumerprolinak és maga nyalja fényesre egy cég seggét, Intelezik/AMD-zik két pofára szendvicsemberként. Akár csak VGA-knál, úgy CPU-knál is megnézem, ár értékben mi a jobb és azt veszem. Intel vs AMD vitában függ attól hogy kinek kell, mire szeretné használni és azon a területen melyik a jobb.

OFF: Érdekes még megnézni a coreboot oldalán a vonatkozó írást. Egy ~5 megás firmware, teljes memória hozzáféréssel és saját network stackkel :-D
https://www.coreboot.org/Binary_situation

Vagy azt, amivel az elmúlt 20 évben kevesebbet szopott. Az AMD processzor gyengéi mindig is a körítésben voltak keresendők. Kritikán aluli alaplapok, chipkészletek, firmware-ek. Elegendőek voltak arra, hogy ha az ember biztosra akart menni, akkor AMD helyett egy helyről mindent:

- Intel chipes alaplap
- Intel processzor
- Intel WiFi
- Intel video

Még így is érheti meglepetés az embert, de aki ésszel él, igyekszik minimalizálni a pofára esés esélyét.

--
trey @ gépház

És akkor még csak a laptopról beszéltem, de elidőzhetünk a virtualizáció és társai témakörben is. Ahol elég az Intel problémáit gyomlálni, ahhoz van elég visszajelzés, telepített teszt és éles bázis, a kutya nem akarja még egy másik gyártó termékét és annak összes körítését a nyakába venni.

Nem beszélve arról, hogy a nagy gyártók szervermegoldásai nem, vagy csak elvétve tartalmaznak AMD processzort és valljuk be, ezen gyártók sem nagyon akarják a világot Intelről AMD-re fordítani.

--
trey @ gépház

A körítés is tud érdekes lenni.
Láttam már instabil full inteles lapot bugos BIOS miatt, vagy pedig azért mert az alkatrészek és az összeszerelés nem volt minőségi.
AMD-nél is megvan az, hogy egy rendesen összerakott márkás alaposan letesztelt cuccal nincs gond.

Legjobb példa a Realtek hálókártya esete. Sokan szidják, viszont vannak olyan gyártók akik rendesen összerakják és nincs velük gond.
-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

Várjuk ki a végét! Egyelőre ott tartunk, hogy Matthew Dillon - kezdőnek egyáltalán nem nevezhető kernelprogramozó és hasonló hibák szakértője ( Az AMD megerősítette, hogy Matthew Dillon CPU bugba botlott - deja vu gyanús) - egyelőre tanácstalan, hogy ki tehet róla.

--
trey @ gépház

( Dwokfur v | 2017. 06. 06., k – 20:21 )

Az ilyen hibák a legidegesítőbbek. Lehet akár egy kernel bug is, de nagyon errata szaga van a dolognak. Remélem nem cseszett el valamit szegény AMD a Ryzen-nel is, mert mindenkinek jobb lenne, ha az új architektúra felvenné a versenyt az Intel-ével...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Az utóbbi években vicces volt nézni a TSX-NI-t, ahogy szépen sorban, majd minden processzorban kikapcsolgatta az Intel. 1-2 ritkább processzorban - amit nem tesztelt ki a közösség olyan alaposan - talán még mindig bekapcsolva hagyja a microcode...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( asch v | 2017. 06. 06., k – 22:13 )

Az ilyen duplán perverzekkel nem lenne szabad foglalkozni!4!! Nem elég, hogy AMD Intel helyett, de Gentoo Ubuntu helyett!!4! Nooormális?

( asch v | 2017. 06. 06., k – 22:14 )

A viccet félretéve, úgy látszik, lassan elérjük a technológiai szingularitást, amikor már egyáltalán nem értjük, hogy valami miért pont úgy működik, ahogy. Jön egy hiba, és senkinek semmi fogalma nincs, hogy mi okozhatja :-).

Nevezhetjük ezt a publikus béta (alfa?) tesztelők elektronikus társadalmának?
Egy processzor gyártó helyében alapból beraknám a tesztek közé, hogy forgassanak vele Gentoo alatt egy world-öt.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Számítógéppel :D , esetleg utólagos "kézi" optimalizálások, ahogy hallottam. Nem tranzisztoronként kell hanem nagyobb részegységekből összeállítani, meg pl cache esetén megadják a kaputípust, kapacitást, aztán majd legenerálja a program a kapukat.
Talán a Z80 volt amit még kézzel skicceltek fel és kézzel szerkesztett rajzokból világítottak le.

Generálnak egy halom réteg maszkot a tervekből, esetleg torzítják, hogy egyensúlyozza a levilágítás torzításait, aztán jöhet a több rétegnyi világítás (mostanában UV, ha jól rémlik még röntgennel is próbálkoznak)/különféle "szennyezőanyagok" felvitele/maratás vagy a franc tudja még mi a szilicium szeletre vagy SOI esetén megmondom őszintén nem tudom pontosan mire :D. Aztán szeletelik, optikailag csekkolják, tokozzák, tesztelik vagy ami még kell. Ez egy dollár milliárdokat felemésztő biznic, persze később be is hozza azokat a milliárdokat töbszörösen, jó esetben.

Brian Bagnall könyvében a Commodore a company on the edge c. könyvében írja hogy a 6502-es tervezésekkor a mérnökök zsebében mindig ott lapult egy kis fémvonalzó avval méricskélték hogy jók e a tervek..ha jól emlékszem 7 rétegből állt a tervrajz és egy réteg kb. egy focipálya méretű lett volna ha kiterítik 1:1-ben, ezek a rétegek ráadásul egymás fölé helyezve átvilágítva bizonyos pontokon metszeniük kellet egymást... mindezt vonalzóval :)

Szerintem már úgy kell tervezni, hogy vannak olyan blokkok, amik kikapcsolhatóak, és ha van benne hiba, akkor az adott blokkot ki lehet kapcsolni. A gyártástechnológiával adott egy hibaszázalék, és ha 0 hiba lenne megengedhető, akkor szinte egyáltalán nem lenne eladható termék.

A nagy területek tudtommal az ismétlődő részek, főleg a memóriacache-ek. Ezeknek olyan szerkezete van, hogy egy része kikapcsolható. Ugyanígy a sokmagos cuccoknál a magok egy része kikapcsolható. Ha viszont a kritikus részen van hiba, akkor kuka.

( lberes (nem ellenőrzött) | 2017. 06. 07., sze – 06:45 )

Ugyanmar, csak a SPARC az igazi!

--
L

( elod v | 2017. 06. 07., sze – 11:09 )

Az Intel Atom C2000 közben komolyabb eszközöket brick-el mint egy desktop gép. Ryzen-re nagy eséllyel lesz mikrokód frissítés, C2000-nél erősen hardverközeli a hiba.

( Smokey2k | 2017. 06. 07., sze – 11:38 )

Japán amúgy.

...nem ide..
hogy lehet hozzászólást törölni ?