[ Megoldva ] 3700U amdgpu halál

GNOME

Debian 10 alatt szeretnék egy Lenovo C340 (Ryzen 7 3700U) laptopon gnomot életrelehelni. Alapból az amdgpu driver-t használná az X, de az elhasal. Telepítve van, de hiába. Próbáltam radeon, vagy ati driverekkel, szintén meghal. Még a vesa driver sem fut. Jelenleg az fbdev driver-re van kapcsolva az X. Ezzel ugyan megy, de azért eléggé korlátozottan. Nincs fényerőállítás, és a képernyő ki/bekapcsolása sem igazán stabil. Jó lenne egy stabilan működő, a hardverra szánt driver.

Valaki használ X-et Vega 10 grafikus kártyával? Minden hasznos ötletnek örülnék.

  • 618 megtekintés

( uid_6201 v | 2020. 11. 25., sze – 08:37 )

Szerkesztve: 2020. 11. 25., sze – 08:40

Ez esetleg segíthet: https://forums.linuxmint.com/viewtopic.php?t=297917
Igaz Mint, de ettől még hasznos lehet.

Illetve Debian backports-ból frissebb kernel (linux-image-5.8.0-0.bpo.2-amd64) és X-szel kapcsolatos pár dolog még segíthet.

Ha jól látom, végül neki is az új kernel segített. Backports-ból letöltöttem az 5.8.10-es kernelt, de sajnos nálam nem történt változás. Pedig újra is indítottam. :) Próbáltam a kapcsolódó amd-s csomagokat is telepíteni, de azokra azt mondta, már a legfrissebbek. Így ezzel az úttal elakadtam. Ráadásul már a 4.19-es kernelre sem tudok visszaállni. :O

Igen, én is erre jutottam, hogy az xserver-org-video-amdgpu 19.1.0 verzió kellene nekem, de sajnos ez az egyetlen xserver-org-video, ami nincs benne a backports-ban. :(

Próbáltam az amd saját csomagjait is telepíteni, de azokhoz meg a libc6 2.29 kell, ami szintén nincs a backportsban. :(

Ezek után nem látok más esélyt, mint átállni a bullseye (testing) vagy a sid (unstable) verziókra ... igazából nem tudom, melyik a kisebb rizikó.

Az aktuális Debian testing mindig stabilabb az unstabe Sid-nél. De akár a Sid is használható ha belefér az, hogy néha eltörik a frissítéssel pár csomag, ami majd következővel újra működni fog. Nem maga az operációs rendszer unstable hanem a software csomagok nincsenek kellően tesztelve. Nálad jelenleg az operációs rendszer számodra elég fontos része, a grafikai alrendszer instabil. Ennél csak rosszabbat már nem csak jobbat hozhat a testing vagy az unstable ág. Természetesen maguk a szoftverek szinte minden esetben már egyszer stabilnak lettek nyilvánítva a fejlesztőjénél még Sid ágban is. Ritka esetben tartalmaz alpha állapotban levő szoftvert a Debian Sid. A forráskódból fordító Linux disztribúciók erre építenek. Azaz például a binary csomagokra épülő Debian disztribúció Sid ága valójában fejleszője által már releaselhető stabil programokat és verziókat tartalmaz. Adott gépen lefordítva forráskódból szinte mindent lerövidíthető a hosszas unstable -> testing -> stable folyamat és a végeredmény egy friss és stabul rendszer lesz. Viszont a programok fordításának feladata így a userének a gépére hárul. 

Itt valami mágia van!

Frissítettem testingre, de most sem megy. A verziók pedig frissültek.

Az Xorg.0.log most már semmi hibát nem tartalmaz, csak ennyit:

 (EE) Screen 0 deleted because of no matching config section.

A konfigot az Xorg -configure parancsával generáltam ... Nem tudom, mi lehet a baj ...

A helyedben kipróbálnám valami teljesen más Linux disztribúcióval, Manjaro, Fedora stb. Nulláról telepítve. Ha azokkal sem működik Windowszal is. Ha hardverhiba van a háttérben akkor nagyon sok időd mehet el árnyak kergetésével. Jobb ezt minél előbb megvizsgálni. 

Ubuntu live elhasalt, de a Linux Mint Mate felülettel azonnal indult, és mindent rendben vitt.

Megpróbáltam megnézni az xorg.conf fájlt, hogy milyen driver van benne, de nem volt meg az /etc/X11/xorg.conf fájl! Ez hogyan lehetséges?

Az lsmod azonban azt jelezte, hogy az amdgpu modul be van töltve.

Ez alapján úgy tűnik, a hardver rendben van. Így még inkább kíváncsi lettem, miért nem indul el debian alatt?

Megnéztem debian alatt is az lsmod listát. Nincs benne amdgpu. Gondoltam, kipróbálom, és manuálisan elindítom: modporbe amdgpu

És lőn! Ezek után már megy az X az amdgpu driverrel.

Akkor ez hogy is van? Nekem kellene bekonfigurálni, hogy minden indulásnál betöltődjön az amdgpu? Miért nem történik ez meg automatán? Hol kellene ezt korrektül beállítani?

A megoldás, kb: gondolom, mikor úgy észlelte a legelején, hogy hibás az amdgpu driver, létrehozott az /etc/modprobe.d mappában egy blacklist-amdgpu.conf fájlt, amiben az amdgpu modult tiltólistára tette.

:(

Innentől nem töltődött be automatán. Bejegyzés törölve, rendszer automatán használja az amdgpu modult. Minden gyönyörű! :)

Köszönöm a támogatást, és a segítségeket!

( sanyula | 2020. 11. 27., p – 09:34 )

Több gépen megy nekem Debian 10 alatt a fenti processzor / GPU.
Ami kellett:

Nálam ezekkel szépen és hiba nélkül megy az X szerver. Mi nem Waylandos Gnome-ot használunk hanem Mate desktopot. Ez lehet okoz különbséget.

( Raynes v | 2020. 11. 28., szo – 05:37 )

Én 4700U-t használok, abban Vega 7 Renoir GPU van. Igaz én nem Stoneagebianon használom, hanem Artix alatt (ez Arch systemd nélkül, de sima Archon is menne), nem kellett hozzá semmit hekkelni, alapból ment a tárolókban lévő csomagokkal (5.9.10-es kernel, 20201113-as linux-firmware csomag, 20.2-es mesa, 19.1.0-ás xf86-video-amdgpu, ez utóbbi csak a X.org-nak kell, Waylanden nem kéne). Ez sajnos nem olyan stabil, mint a Debian, vagy az Ubuntu LTS, meg nem enterspájz grade, mint a CentOS, ez ilyen komolytalan rolling, amit csak hobbisták használnak, ezzel csak azt tudod csinálni, hogy felteszed és megy. Nem kell hozzá PPA-val, külső tárolóval, free vs. nonfree körfutásokkal, backports-szal vergődni, nincs release party meg nagy bejelentések, ezek az életérzések nem adatnak meg.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Alapvetően nekem vegyesek vele a tapasztalataim. Maga az Artix nem lenne rossz, de
1) kevés mirror van hozzá és azok lassúak
2) OpenRC-vel használom, és az nem a legjobban van implementálva benne, Gentoo alatt olajozottabban, gyorsabban ment ugyanez az initrendszer. Bár fel lehet tenni Artixot runit-tal (azt használtam Void alatt) és S6-tal is (azt még sose használtam)

De szerintem Gentoo-ról már semmi másra nem érdemes váltani, hacsak nem LFS-re. A Gentoo sose fog kifulladni. Azt mondanom sem kell, hogy Gentoo alatt is azonnal mennie kéne a 3700U és 4700U által tartalmazott GPU-nak, csak arra kell figyelni, hogy kernelfordításkor a kernel konfigjában bejelölni, hogy az AMD GPU-kkal kapcsolatos drivert forgassa bele a kernelbe, meg telepíteni a linux-firmware-t és a USE flag-eknél hozzáadni az amd kulcsszót, hogy a X.org fordításakor tudja, hogy melyik xf86-os drivert kell feltenni.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Rendszeresen azt veszem észre, hogy új biztonsági javítások esetén hamarabb patch-elem a programot, mint ahogy az a központi tárolóban megtörténik. Debian-ról azért tértem át Gentoo-ra kb. 18 évvel ezelőtt, mert nagyon le voltak maradva a csomagokkal. Szeretem a Gentoo-t, de sok csomagnál látom a Maintainer needed-et. Érezhetően kisebb a felhasználói bázis, mint a fénykorában (15 évvel ezelőtt). Most inkább Arch-ozni menő. Egyébként tiszteletem az archwiki-nek, rendszeresen használom. Mondjuk a Gentoo bája, hogy könnyű patch-elni a rendszert. Mostanság a Debian-nál sokszor hamarabb kint van a javított csomag...

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

Még soha nem láttam rendszer crash-t arch-on, pedig több mint 10 éve használom. Lehet hardware-t kéne ellenőrizned...

A Linux nem ingyenes. Meg kell fizetni a tanulópénzt. / Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!! / Mindenki jó valamire. Ha másra nem, hát elrettentő példának. /  "Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993

A virtuális gépek világa elég ingatag, azokon bármilyen disztró, meg bármilyen OS könnyebben megborul. Ez nem valós tapasztalat, ha tényleg meg akarod ismerni az Arch stabilitását, tedd fel natívan a gépre és használd huzamos ideig. Ha nincs türelmed telepíteni, tedd fel Manjaro vagy ArcoLinux formájában, akkor is megkapod ugyanazt az Arch-ökoszisztámát, használhatod ugyanazt az AUR-t, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nem tudom, nem használok VirtualBox-ot, de mikor még legutóbb használtam, akkor Mint KDE, Kubuntu, meg WinXP, 7, 10 alatt, ott élből, Arch nélkül sem volt stabil jószág, meg tud borulni hosttól és guest OS-től függetlenül itt-ott. Arch alatt qemu-t használok -enable-kvm kapcsolóval. És ezt könnyen ellenőrizhetitek is, felraktok Ubuntut, Debiant, és meglátjátok, hogy ugyanaz a VirtualBox, ugyanazzal a guest OS-sel ott sem lesz semmivel stabilabb, garantálom egy centivel se. Virtualbox esetében ez ilyen Órököl minőség, az addig volt normális szoftver, mint az Innotek fejlesztette, aztán ment lefelé szép fokozatosan a lejtőn.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ezt a heti egyszeri crash-t csak addig hiszed, amíg nem használsz Archot ténylegesen, mindennapi fő rendszernek. Aztán meglátod, hogy nem hogy heti egyszer, de évi egyszer se lesz crash. Igen, van, amikor frissítésbe kézzel kell beavatkozni, 1-2 alkalmazában előfordul egy kis bug (semmi dealbreaker, semmi nagy rendszert egészében kinyíró, teljesen működésképtelenné tevő nagy dolog), de mindig van rá workaround, és a bugot is elég gyorsan javítják, amilyen gyorsan jön, olyan gyorsan megy. Bár szerintem a Gentoo jobb disztró, nagyobb kontrollt ad a felhasználó kezébe, saját kernellel, saját választású initrendszerrel és logmegoldással még nagyobb szabadságot kínál, és sokkal minimalistább rendszer építhető belőle az Archnál is. Én inkább azokat az embereket nem értem, aki felteszik a Gentoo-t sytemd-vel és KDE-vel, annak nincs értelme, annyi erővel használhatnának Kubuntut, Fedora KDE-t, vagy Archot KDE-vel, whatever, elveszik a Gentoo értelme akkor, és a rengeteg óra fordítgatás a semmi miatt történt.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Igen, a Debian azért fejlődött, már nem annyira elavultak a csomagok, mint sok éve. Bár még most se a frissesség fellegvára, ha valaki a legfrissebb hardvereket akarja hajtani, meg a legfrisebb Proton, akármi kell neki, akkor arra továbbra sem való.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

"Nem kell hozzá PPA-val, külső tárolóval, free vs. nonfree körfutásokkal, backports-szal vergődni, nincs release party meg nagy bejelentések, ezek az életérzések nem adatnak meg."

 

jaja... s még az ilyen nyalánkságok sem, mint dependency hell... hogy az ember felrak egy smartmontools-t, ami magával ránt egy mailszervert... meg az a rohadt lassú dpkg....

( prozherum v | 2020. 11. 29., v – 05:10 )

Arch linux-on hasznalom a kovetkezo kernel parametereket ezzel az APU-val:

radeon.cik_support=0 amdgpu.cik_support=1 radeon.si_support=0 amdgpu.si_support=1

Szerintem ezek a kernelopciók feleslegesek. Nem ártanak, de nem is segítenek semmit. Nem kellettek se a topiknyitónak a megoldáshoz, se nekem (egyel újabb generációs APU-t használok). Mennie kéne külön varázslás nélkül, alapvetően mindent kéne vigyen az amdgpu KMS kerneldriver és a mesa. Aki X.org-ot használ, az még az xf85-videoa-amdgpu-t felteheti és a hardveres videódekódoláshoz a libva-mesa-drivert, meg a vulkan csomagot a Vulkan támogatásoz és ennyi.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ja, az lehet, hogy azon segíteni fog. De a suspend-ből visszajövetel Linux alatt, akármilyen disztró alatt is állandóan problémás, nem csak GPU-tól függ, de CPU-tól, alaplapi chipsettől, BIOS-tól. Elég ritka kivétel, ha valakinek tényleg probléma nélkül megy, értem ezalatt, hogy nem csak lemegy suspendbe, sleepbe, stb., de onnan az esetek 100%-ban visszajön használható állapotúra a rendszer, glitchek nélkül. Suspenddel így 2020-ban nem is nagyon érdemes szenvedni, nagyobb DE-k és editorok tudnak session kezelést, és SSD-ről a boot pár másodperc, alig hosszabb, mintha suspendből jönne vissza a gép.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”