Phoronix - Az AMD megerősítette, hogy Linux alatt vannak segfault problémák egyes Ryzen processzorokkal

 ( trey | 2017. augusztus 8., kedd - 8:36 )

A phoronixos Michael Larabel rendszeresen futtat stresszteszteket Linux alatt különféle hardverkonfigurációkon. A közelmúltban AMD Ryzen processzorokat nyúzott Linux alatt, mikor is visszajelzések / kérések nyomán arra jutott, hogy komoly terhelés (pl. párhuzamos fordítás) közben segmentation fault problémákba ütközhet a felhasználó.

Larabel szerint az AMD elismerte, hogy sikerült reprodukálniuk a problémát és együttműködnek az érintett felhasználókkal a megoldás keresésében. Az AMD a problémát nagyon komplexnek írta le. A probléma más UNIX(-szerű) rendszerek (pl. FreeBSD) felhasználóit is érintheti. Az egyelőre nem ismert, hogy a Matthew Dillon által említett BSD-s Ryzen probléma összefüggésben van-e ezzel, vagy sem, de Larabel szerint nincs köze a Ryzen-nel összefüggő FreeBSD guard page problémához.

A cikk szerint az AMD kijelentette, hogy a probléma nem érinti az AMD Epyc és AMD ThreadRipper processzorokat. Azok a Ryzen tulajdonosok, akik úgy hiszik, őket is érinti a probléma, felvehetik a kapcsolatot az AMD Customer Care ügyfélszolgálattal.

Részletek itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Azért egy AMD szintű gyártó igazán beilleszthetne az alap processzor tesztjei közé néhány non-Windows alapú stressz tesztet is. Ha nem akarnak sokat bíbelődni Gentoo-val vagy Arch-csal, akkor elég lenne egy Ubuntu és a Phoronix test. És nem lennének ilyen betlik. Mert ha tudtak volna róla, akkor már szerintem eleve olyan mikrokóddal jelent volna meg a CPU, hogy ne legyenek ilyen pofára esések. De úgy érzem, hogy most ők is csak keresik az okot. Ha tovább látnának a teszt laborban, mint a 3DMark, akkor máris jobban tudták volna kezelni a helyzetet. Félreértés ne essék: ugyanúgy igaz ez az Intel-re is, akik szintén beleszaladtak már hasonlóba. Csak azért fogom a fejem, mert a verseny miatt drukkolok az AMD-nek az új architecturájához, de megint sikerül nekik egy Bulldozer-hez hasonló Errata-val nyitni. Mi a pikuláért nincs egy Linux-os test-bed ott a laborban? Azt a lámer mindenit már neki.

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

Azt ígérték lesz:

"AMD will also be stepping up their Linux testing/QA for future consumer products."

--
trey @ gépház

Ez nagyon gáz. Ez azért nagyon sovány QM.

Igen, az a ciki benne, hogy egy 8C/16T-s CPU, ráadásul ECC-memória támogatással lényegében egy "light"-workstation. Szerintem igen sokan szeretnék fejlesztőgépnek vagy akár olcsó build szervernek venni és amúgy sokkal jobban passzol is erre a célpiacra, mint gamer gépnek. Arról nem beszélve, hogy a játékok többsége még mindig 4 threadre van optimalizálva.

És mivel ugyanerre az IC-re tervezték a Threadrippert és a kifejezetten szervebe szánt EPYC-et is, miközben szerver-oldalon azért nem 2% a Linux részesedése és nem 2% fogja intenzív szoftverfordításra használni (és itt nem Arch meg Gentoo userekről van szó, hanem azokról a nagy customerekről, akik bevágják jenkins slave-nek és nyomják rá 1000 szálon a build jobokat). Valahogy mintha ez meglepte volna az AMD-t. Egyébként is az EPYC mint márkanév egy szerverbe szánt terméknél... még jó, hogy RGB LED nem villog a kupak alól :)
---
Régóta vágyok én, az androidok mezonkincsére már!

Bizony nem kell messzire visszamenni, ami az Intelt illeti, pont most volt hír a Prohardveren, hogy az X399-es lapokon nem lesznek bootolhatóak az NVMe PCIE RAID, csak ha vásárol valaki hozzá külön inteles hardveres kulcsot. Legalja, mehetne ki a demotiválóra, napiszarra vagy a kurucinfóra is. Igazából egyik nagy tech cég sem különb.


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Nem is lenne AMD, ha minden menne flottul. A következö az lesz, hogy Windows alatt is...
Egyébként meg nincs semmi meglepö abban, hogy egy új processzor nem müködik szoftveresen annyira, mint egy régi. Idövel megoldják (vagy nem).

--
robyboy

Windows alatt se indult hibamentesen.

Bizony. Sőt konkrétan ezt a hibát is reprodukálták Windows alatt, WSL-el. Vagyis lényegében semmi Linux-specifikus nincs benne. Egyszerűen a gcc és a clang provokálja a legjobban.
---
Régóta vágyok én, az androidok mezonkincsére már!

Ez mindig nagyon tetszik, amikor egy gyártó egy probléma kapcsán azzal válaszol, hogy a probléma "bonyolult".

Én nem emlékszem eddig ilyen válaszra egy gyártótól :)

Én viszont mondtam ilyet már főnöknek :)

És erre az a szabvány főnöki válasz, hogy "ha egyszerű lenne a feladat, akkor nem te kapnád".

Vegre itt a Linux desktop eve! A bugzo es/vagy evekkel kesobb tamogatott GPU, hang es WiFi melle most mar CPU bugokkal is!

Pedig pont most orultunk rajta, hogy eljott minden idok legtobbb mazochistajalegnagyobb desktop reszesedese :))

Igazolva érzed magad csak azért mert az AMD kihozott egy _bugos cpu_ -t? (leírni is mókás).

"evekkel kesobb tamogatott GPU, hang es WiFi melle"

Az ezredforduló óta eltelt már pár év, próbáld ki nyugodtan mostanában mi a helyzet :)

--
arch,debian,retropie,osmc,android,windows

Minden CPU bugos egyebkent, ez tok termeszes egy ilyen komplexitasu termek eseten.

----------------------
while (!sleep) sheep++;

Mas tema ha egy mezei multithread compile ki is hozza :)

--
arch,debian,retropie,osmc,android,windows

Igen. Ès akkor müködik stabilan egy rendszer, amikor egy -vagy több- hiba kioltja egymást.

--
robyboy

Vagy 30 éve foglalkozok gépekkel, és nekem még sose fagyott le vagy segfaultolt gép procibug miatt. Procitúlmelegedés, szar chipset, elhalálozó memória miatt többször, de CPU-val sose volt még gondom, egészen az i7 különböző generációiig bezárólag, Ryzen vagy i9 ügyében nem tudok nyilatkozni. Pedig mikrokódfrissítést sem használtam soha.

Egyébként én már akkor felhördültem, mikor valamelyik PH-s hír lehozta, hogy a modern procikat már tervezéskor Windowsra optimalizálják. Honnan tudják, hogy windowsozni fogok rajta, mikor pedig nem is? Persze a sok troll leoltott a 0%-os linuxos részesedéssel meg a soha nem jön el a desktop linux évezrede mantrákkal, meg hogy mi másra optimalizálnák, mint Windowsra, de pont most ennél a hírnél szépen látszik, hogy blama az egész. Az csak hab a tortán, hogy a Ryzeneknek Windows alatt is frissítés kellett az optimalizációhoz, meg módosítani kellett az energiagazdálkodási sémát, különben voltak velük teljesítményproblémák.


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

"Pedig mikrokódfrissítést sem használtam soha."

Ezt így kategórikusan kijelenteni nem merném. Egyrészt a BIOS is tartalmazza őket, de az oprendszer is.

Sürgette őket az idő... és a kapkodás sosem vezet jó eredményre.

--
robyboy

> Igazolva érzed magad csak azért mert az AMD kihozott egy _bugos cpu_ -t? (leírni is mókás).

Leirni valoban mokas, de egyreszt ahogy a kollega irta, minden CPU tele van bugokkal, masreszt most nem CPU bugrol volt szo, hanem bugos driverrol. Legalabbis amikor valami csak bizonyos OS-en jon elo, az igen hatarozottan szoftveres problemanak tunik, nem pedig hardveresnek.

> Az ezredforduló óta eltelt már pár év

Pedig en azt hittem, megallt az ido \o/

> próbáld ki nyugodtan mostanában mi a helyzet :)

Koszonom a tanacsot, napi szinten szopunk vele, gepek szazain. A kedvencem, amikor a WiFi-hez a firmware-t random GitHub repokbol kell beletaknyolni egy random mappaba, hogy egyaltalan szoba alljon velem a NetworkManager. Es ez igy marad evekig, de mire a laptop mar reg elavult, addigra talan sikerul abszolvalni ezt a komplex csomagolasi muveletet.

Meg az is jo, amikor az USB-s adapter 1 perc utan indul csak el. Addig meg nem megy a login, mert hat LDAP a login, nem local. Mondjuk be van neki allitva, hogy cache-elje a credential-okat, ami neha mukodik is. Neha meg nem.

Meg az is jo, amikor a GPU driver a login screen-ig kepes mukodni, de a jelszo beirasa utan csak villan egyet, aztan kidob ujra a login screen-re. A hivatalos vendor driver-rel termeszetesen, tobb driver verzioval, tobb os release-zel. Az openszosz driver persze ugyesen be tud jelentkezni. Az csak minden masban szar. Nem, nem lowend, nem budget. Titan X, es ilyen "hulladek" vasak.

Meg az is jo, amikor ugyanez a GPU kernel modul elpanikoltatja a kernelt. Rendszeresen.

Meg a tobbszazezres enterprise 40G Intel NIC, hivatalos Linux tamogatassal, ami Windows-on atomstabilan megy, Linuxon meg hetente elfossa magat. Csak par masodpercre, de az pont eleg arra, hogy a jobok megdogoljenek. Tobb driver verzioval, tobb os release-zel.

Es akkor most kerek ide legalabb meg 5 fanboy-t, aki leirja, hogy neki marpedig mukodik a Linux. Nagyon orulunk, ugyesek vagytok, borzaszto sokat tesztek hozza a temahoz.

Milyen területen dolgozol ahol ekkora a minta? Többszáz gép? Egyformák, vagy nagyon sokfélék? Csak azért mert az átlagos otthoni PC-k 99%ánál OOTB szokott menni minden, és nemigen vannak már ilyen problémák.

szerk.: természetesen hiszek neked, de ez azért az extrém méretű minta esete, lássuk be. És nem mondta senki azt sem, hogy _soha_ nincs _semmilyen_ hardvertámogatós probléma, csak az átlagos eset javult sokat.

--
arch,debian,retropie,osmc,android,windows

A felhozott peldak mind reprodukalhatoak ugye es midnen esetben kiderul:
- a gyarto nem keszitette el a termeket Linuxra, hanem az alatala adott binaris ugy-szar-ahogy-van firmware-et adja csak
- masik eset, amikor elkeszitek a moduljukat a 2.1-es kernelre es mukodnie kellene a 17.18-assal is (szerintuk)
- aztan ott van, amikor kiadjak ujra es ujra, csak hat nem kovetik a kernel valtozasait benne (pedig egy ifdef nem olyan bonyolult; pl. routerbe dughato networkdisk driver ahol valtozott egy struct a kernel oldalan, de ok a regit hasznaltak meg mindig de legalabb nyilt forrasu volt)

Ez a Linux egy szar, hogy nem kepes feketedobozokat mukodteteni...Blablahblahblah...rinya rinya rinya :D

Hát sokat épp te se teszel hozzá, csak fikázol, azzal meg senki sincs előrébb.
Havernál brand unix+gyári rdbms upgrade után a dbms néha eldobálta a kapcsolatokat. Párnaponta megtörtént (eleinte gyakrabban), aztán magához is tért, csak ez pont elég volt ahhoz hogy minden magába forduljon ami erre épül. Mindenki tud ilyen történeteket...

Azért jelentkezzen aki érti, hogy mit is jelent a "Performance marginality problem"!
---
Régóta vágyok én, az androidok mezonkincsére már!

Igen olvastam :)
És elég intenzíven gugliztam is utána, de egyszerűen ez a kifejezés így alig-alig fordul elő, és leginkább közgazdászok használják értékpapírokra. :)
---
Régóta vágyok én, az androidok mezonkincsére már!

Lehet, hogy valami hasonloval talaltak ki a kifejezest: http://www.atrixnet.com/bs-generator.html :D