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

AMD

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.

( Dwokfur v | 2017. 08. 08., k – 10:12 )

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

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

( uid_16313 | 2017. 08. 08., k – 10:17 )

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

( cus | 2017. 08. 08., k – 10:46 )

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

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

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

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

( XMI | 2017. 08. 08., k – 14:23 )

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!