Nedávno jsem narazil na zcela nový hardwarový problém s distribucí Linuxu. V Linux Mint 20.2 se při spouštění na baterie, tj. bez šťávy ze zásuvky, proces spouštění v určitém okamžiku zastaví a zobrazí se nereagující černá obrazovka. Jediným řešením je restartovat počítač nebo zapnout hostitele s připojenou nabíječkou.
Zajímavé je, že se tak stalo na relativně novém notebooku IdeaPad 3 s grafikou AMD Vega 8. A dost mě to štvalo, protože se vždycky zdá, že je nějaký problém s hardwarem. Bezdrátové na tomto stroji, grafika na tomto, I/O ovládání tady, kamera tam a tak dále. Vždy problémy, vždy výmluvy. No, podívejme se, co zde můžeme udělat a jak to napravit.
Problém podrobněji
Narazil jsem na problém s Linux Mint. Ale mám podezření, že se problém týká mnohem širší základny. Pokud hledáte „černá obrazovka spouštění AMD“, získáte spoustu výsledků pro vlákna fóra, ať už jde o Ubuntu, Mint, Arch, Manjaro nebo Gentoo, pocházející z roku 2019, se spoustou doporučení a velmi málo skutečných řešení. . Proč? Protože oprava problémů s ovladači vyžaduje odborné znalosti, a pokud vaše jádro a/nebo ovladače nenabízejí správný druh funkčnosti, nemůžete toho moc dělat. Tím se také zaměří na otázku ovladačů s otevřeným zdrojovým kódem a ovladačů s uzavřeným zdrojovým kódem, jako by na tom byl nějaký rozdíl. Není, protože odbornost je odbornost.
Pomineme-li mini-rant, počítač IdeaPad 3 má konfiguraci s trojím spouštěním, včetně také MX-21 KDE a Windows. Vzhledem k tomu, že tyto další dva systémy fungují bez problémů, mohl bych vyloučit problém s hardwarem a zaměřit se na to, co je konkrétně špatné (a odlišné) se zaváděcí sekvencí Mint.
Za tímto účelem jsem vzal soubory dmesg, kern.log, X.org.log a systémové protokoly z Mint a MX-21 a porovnal je vedle sebe, přičemž jsem dělal skutečné rozdíly. Jediný skutečný rozdíl je v protokolu jádra, kde Mint přestane bootovat, zatímco ostatní distribuce vesele pokračuje. Chyba zní takto:
...
kernel:[] [drm:amdgpu_job_timedout [amdgpu]] *CHYBA* Informace o procesu:proces Xorg pid 790 vlákno Xorg:cs0 pid 824
kernel:[] amdgpu 0000:03:00.0:Reset GPU začíná!
kernel:[] amdgpu 0000:03:00.0:Reset GPU byl úspěšný, pokus o obnovení
jádro:[] [drm] PCIE GART 1024M povoleno (tabulka na 0x000000F400900000).
kernel:[] [drm] PSP se obnovuje...
kernel:[] [drm] rezerva 0x400000 z 0xf47f800000 pro PSP TMR
kernel:[] [drm] příkaz psp selhal a stav odpovědi je (0x7)
kernel:[] [drm] VCN dekódování a kódování úspěšně inicializováno (v režimu SPG).
kernel:[] amdgpu 0000:03:00.0:ring gfx používá VM inv eng 0 na hubu 0
...
Reset GPU se nakonec podaří, ale nepomůže. Obrazovka zůstane černá. Nyní vám ukážu, jak můžete problém vyřešit nebo obejít. Máme k dispozici několik možností.
Řešení
OK, takže můžete udělat toto:
Nainstalujte nové jádro (pokud je k dispozici)
Aktualizujte systémové jádro a/nebo firmware. V Linux Mintu, který normálně připíná jádra, si můžete ručně stáhnout nové pomocí nástroje System Update. Upozorní vás a poté můžete vybrat požadovanou verzi a nakonfigurovat ji. U Mint 20.2 Uma můžete přejít z jádra 5.4 na jádro 5.13.
Když jsem nainstaloval nové jádro a podíval se na konfigurační výstup, všiml jsem si také sady varovných zpráv během generování souboru initramfs:
...
W:Možná chybějící firmware /lib/firmware/amdgpu/vangogh_vcn.bin pro modul amdgpu
W:Možná chybějící firmware /lib/firmware/amdgpu/navy_flounder_vcn.bin pro modul amdgpu
W:Možná chybí firmware /lib/firmware/amdgpu/navi12_vcn.bin pro modul amdgpu
W:Možná chybí firmware /lib/firmware/amdgpu/aldebaran_vcn.bin pro modul amdgpu
...
Tyto můžete ignorovat, pokud se vaše architektura GPU AMD v tomto seznamu nezobrazuje. V mém případě byla Vega 8 správně podporována (tj. není v tomto seznamu). jak se to pozná? Můžete spustit příkaz lspci -v, který vypíše všechny vaše různé hardwarové komponenty. Potřebujete záznam, který odpovídá správnému používanému ovladači jádra, v tomto případě amdpu.
03:00.0 VGA kompatibilní řadič:Advanced Micro Devices, Inc. [AMD/ATI] Picasso (rev c2) (prog-if 00 [VGA řadič])
Subsystém:Lenovo Picasso
...
Tímto způsobem jsem zjistil, že moje grafika Vega 8 skutečně odpovídá modelu architektury zvanému Picasso. Myslím, že to obecně vysvětluje použité názvy. Tento výstup je jen neuspořádaný šum, který vám říká, že nová jádra nepodporují určité modely GPU. Opět to otevírá širší otázku zpětné kompatibility Linuxu a podobně, ale o tom teď nebudeme diskutovat. Restartujte a to by mělo, doufejme, fungovat.
Spusťte hostitele se zapojeným napájením
To je nepříjemné, ale je to jednoduché řešení, pokud se necítíte pohodlně s prováděním jakýchkoli změn systému nebo pokud nechcete dělat nic zvláštního, dokud vaše distribuce Linuxu problém nevyřeší. Tento problém však zdůrazňuje jednu (malou) nevýhodu zásad jádra Mint a obecný, širší fenomén hardwarové podpory v Linuxu. Protože pokud vaše distribuce nemá k dispozici aktualizované jádro, nemůžete toho moc udělat.
Důvod, proč tento „trik“ funguje, je ten, že systém pod plným výkonem (na rozdíl od napájení z baterie) používá různé profily napájení. Pokud jste opravdu důvtipní, můžete si pohrát s možnostmi výkonu systému BIOS, pokud jsou k dispozici, nebo upravit nastavení napájení GPU, ale to je pouze dočasné opatření.
Změňte parametry spouštění
Pokračujeme v tom, co jsem zmínil dříve, můžete spustit systém předáním řady různých parametrů modulu jádra AMD GPU (amdgpu). Jaký druh parametrů a voleb modul podporuje, můžete zkontrolovat spuštěním příkazu modinfo:
modinfo amdgpu
název souboru:/lib/modules/5.13.0-22-generic/kernel/drivers/gpu/drm/amd/amdgpu
/amdgpu.ko
licence:GPL a další práva
popis:AMD GPU
autor:AMD linux driver team
...
parm:audio:Audio povoleno (-1 =auto, 0 =zakázáno, 1 =povolit) (int)
parm:disp_priority:Priorita zobrazení (0 =auto, 1 =normální, 2 =vysoká) (int)
parm:hw_i2c:hw i2c motor povolen (0 =zakázán) ( int)
parm:pcie_gen2:PCIE Gen2 mode (-1 =auto, 0 =zakázání, 1 =povolení) (int)
parm:podpora msi:MSI (1 =povolení, 0 =zakázání, - 1 =auto) (int)
...
Například některé z dostupných možností můžete vyzkoušet – ale NE, pokud nerozumíte tomu, co děláte!
amdgpu.noretry=0
amdgpu.dc=1
Ty je třeba přidat do zaváděcího řádku jádra v zaváděcí nabídce. U nejnovějších distribucí Linuxu, které používají zavaděč GRUB2, je pořadí příkazů následující:
- Otevřete /etc/default/grub v textovém editoru jako root nebo sudo (předem vytvořte zálohu)
- Přidejte jednu nebo více možností amdgpu do řádku GRUB_CMDLINE_LINUX_DEFAULT.
- Uložte soubor a aktualizujte konfiguraci GRUB pomocí:
sudo update-grub
Nebo v systémech, které nepoužívají výše uvedený skript wrapper:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Restartujte systém a zjistěte, zda je váš problém vyřešen. Můžete zkontrolovat, jak se systém nabootoval, prozkoumáním příkazového řádku jádra - nebo spíše, pokud se bootuje z baterie v pořádku, ha ha!
cat /proc/cmdline
Nyní je velkou otázkou, které možnosti amdgpu byste měli přidat?
Na to neexistuje jednoduchá odpověď, obávám se. Ve většině případů, kromě skutečné opravy jádra/firmwaru, budete hádat na základě chybové zprávy, kterou vidíte v protokolu jádra, a doufat, že konkrétní volba může stačit. Důvodem je to, že chybové zprávy jsou často obecné a bez odborných znalostí v grafickém zásobníku a konkrétním ovladači to opravdu nemůžete vyřešit hrstkou možností modulu jádra.
Provádění těchto úprav může potenciálně vést k dalším problémům a komplikacím, a proto byste je neměli slepě používat nebo pouze kopírovat jakýkoli návrh z fóra. Moje testování ukazuje, že žádná možnost ve skutečnosti nemá žádný velký rozdíl. Dva výše uvedené jsou pouze pro informaci. Přesto, pokud aktualizace jádra nefungují a musíte být schopni používat notebook na baterie, pak myslím, že nemáte co ztratit a můžete také experimentovat a zjistit, co to dá.
Závěr
Tam jedeme. Doufejme, že váš notebook s grafikou AMD se systémem Linux se nyní chová správně a při spouštění při napájení z baterie (nebo v jiném scénáři) již nevidíte problém s černou obrazovkou. Můj tutoriál nastiňuje tři hlavní přístupy:upgrade jádra, řešení spotřeby energie a nějaký hacking s parametry modulu jádra, které jsou riskantní a s největší pravděpodobností vám nepřinesou nejlepší výsledky, ale hej.
Nemám rád tento druh problémů. Vždy mi připomínají, jak je Linux křehký. Ano, běží na tunách hardwaru, a to je chvályhodné, ale vždy je to 95 % nebo 91 %, nikdy 100 % skrz naskrz. A to je nepříjemné. No, každopádně to je ono. Teď jdu na svou další Tuxy překážku. Uvidíme se.