Di recente, ho riscontrato un nuovissimo problema relativo all'hardware con una distribuzione Linux. In Linux Mint 20.2, durante l'avvio a batteria, ovvero senza presa a muro, il processo di avvio si interrompeva a un certo punto, con una schermata nera che non rispondeva. L'unica soluzione è riavviare o accendere l'host con il caricabatterie collegato.
Ciò che è interessante è che ciò è accaduto su un laptop IdeaPad 3 relativamente nuovo con grafica AMD Vega 8. E mi ha infastidito molto, perché sembra che ci siano sempre dei problemi con l'hardware. Wireless su questa macchina, grafica su questa, controllo I/O qui, fotocamera là e così via. Sempre problemi, sempre scuse. Bene, vediamo cosa possiamo fare qui e come risolverlo.
Problema in dettaglio
Ho riscontrato il problema con Linux Mint. Ma sospetto che il problema riguardi una base molto più ampia. Infatti, se cerchi "schermata nera di avvio AMD", otterrai tonnellate di risultati per i thread del forum, siano essi Ubuntu, Mint, Arch, Manjaro o Gentoo, risalenti al 2019, con tonnellate di consigli e pochissime soluzioni effettive . Come mai? Perché risolvere i problemi con i driver richiede esperienza e se il tuo kernel e/oi driver non offrono il giusto tipo di funzionalità, non c'è molto che puoi fare. Ciò mette anche a fuoco la questione dei driver open source rispetto a quelli closed-source, come se ciò facesse la differenza. Non è così, perché la competenza è competenza.
Mini-rant a parte, la macchina IdeaPad 3 ha una configurazione a triplo avvio, che include anche MX-21 KDE e Windows. Poiché questi altri due sistemi funzionano senza alcun problema, potrei escludere un problema hardware e concentrarmi su ciò che è specificamente sbagliato (e diverso) nella sequenza di avvio di Mint.
A tal fine, ho preso i file di registro dmesg, kern.log, X.org.log e di sistema da Mint e MX-21 e li ho confrontati, fianco a fianco, facendo le differenze effettive. L'unica vera differenza è nel registro del kernel, dove Mint interrompe l'avvio mentre l'altra distribuzione continua allegramente. L'errore si legge come segue:
...
kernel:[] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Informazioni sul processo:process Xorg pid 790 thread Xorg:cs0 pid 824
kernel:[] amdgpu 0000:03:00.0:Inizia il ripristino della GPU!
kernel:[] amdgpu 0000:03:00.0:ripristino della GPU riuscito, tentativo di riprendere
kernel:[] [drm] PCIE GART di 1024M abilitato (tabella 0x000000F400900000).
kernel:[] [drm] PSP sta riprendendo...
kernel:[] [drm] riserva 0x400000 da 0xf47f800000 per PSP TMR
kernel:[] [drm] comando psp non riuscito e lo stato della risposta è (0x7)
kernel:[] [drm] Decodifica e codifica VCN inizializzate correttamente (in modalità SPG).
kernel:[] amdgpu 0000:03:00.0:ring gfx usa VM inv eng 0 sull'hub 0
...
Alla fine, il ripristino della GPU riesce, ma non aiuta. Lo schermo rimane nero. Ora lascia che ti mostri come puoi risolvere o aggirare il problema. Abbiamo alcune opzioni a nostra disposizione.
Soluzioni
OK, ecco cosa puoi fare:
Installa un nuovo kernel (se disponibile)
Aggiorna il kernel di sistema e/o il firmware. In Linux Mint, che normalmente blocca i kernel, puoi scaricarne manualmente uno nuovo tramite l'utilità System Update. Ti avviserà, quindi potrai selezionare la versione desiderata e configurarla. Per Mint 20.2 Uma, puoi passare dal kernel 5.4 al kernel 5.13.
Quando ho installato il nuovo kernel e ho guardato l'output della configurazione, ho notato anche una serie di messaggi di avviso durante la generazione del file initramfs:
...
W:Possibile firmware mancante /lib/firmware/amdgpu/vangogh_vcn.bin per il modulo amdgpu
W:Possibile firmware mancante /lib/firmware/amdgpu/navy_flounder_vcn.bin per il modulo amdgpu
W:Possibile firmware mancante /lib/firmware/amdgpu/navi12_vcn.bin per il modulo amdgpu
W:Possibile firmware mancante /lib/firmware/amdgpu/aldebaran_vcn.bin per il modulo amdgpu
...
Puoi ignorarli SE la tua architettura GPU AMD non viene visualizzata in questo elenco. Nel mio caso, Vega 8 è stato supportato correttamente (cioè non in questo elenco). Come si fa a saperlo? Bene, puoi eseguire il comando lspci -v, che elencherà tutti i tuoi diversi componenti hardware. È necessaria la voce che corrisponde al driver del kernel corretto in uso, in questo caso amdpu.
03:00.0 Controller compatibile VGA:Advanced Micro Devices, Inc. [AMD/ATI] Picasso (rev c2) (prog-if 00 [controller VGA])
Sottosistema:Lenovo Picasso
...
In questo modo, ho scoperto che la mia grafica Vega 8 corrisponde in realtà a un modello di architettura chiamato Picasso. Immagino che questo spieghi i nomi usati, in generale. Questo output è solo un rumore disordinato che ti dice che i nuovi kernel non supportano determinati modelli di GPU. Ancora una volta, questo apre una questione più ampia sulla compatibilità con le versioni precedenti di Linux e simili, ma non ne discuteremo ora. Riavvia e, si spera, questo dovrebbe fare il lavoro.
Avvia l'host con l'alimentazione collegata
Questo è fastidioso, ma è una semplice soluzione alternativa se non ti senti a tuo agio nell'apportare modifiche al sistema o se non vuoi fare nulla di speciale fino a quando la tua distribuzione Linux non risolve il problema. Tuttavia, il problema evidenzia un (piccolo) aspetto negativo della politica del kernel di Mint e un fenomeno generico e più ampio di supporto hardware in Linux. Perché, se la tua distribuzione non ha un kernel aggiornato disponibile, non puoi fare molto.
Il motivo per cui questo "trucco" funziona è perché un sistema a piena potenza (al contrario dell'alimentazione a batteria) utilizza profili di alimentazione diversi. Se sei davvero esperto, puoi giocare con le opzioni di prestazioni energetiche del BIOS, se disponibili, o modificare le impostazioni di alimentazione della GPU, ma questo è inteso solo come misura temporanea.
Modifica i parametri di avvio
Continuando ciò che ho menzionato prima, puoi avviare il sistema passando una gamma di parametri diversi al modulo del kernel della GPU AMD (amdgpu). Puoi controllare che tipo di parametri e opzioni supporta il modulo eseguendo il comando modinfo:
modinfo amdgpu
nome file:/lib/modules/5.13.0-22-generic/kernel/drivers/gpu/drm/amd/amdgpu
/amdgpu.ko
licenza:GPL e diritti aggiuntivi
descrizione:AMD GPU
autore:AMD linux driver team
...
parm:audio:Audio enable (-1 =auto, 0 =disable, 1 =abilitato) (int)
parm:disp_priority:Display Priority (0 =auto, 1 =normale, 2 =alto) (int)
parm:hw_i2c:hw i2c engine enable (0 =disabilita) ( int)
parm:pcie_gen2:PCIE Gen2 mode (-1 =auto, 0 =disabilita, 1 =abilita) (int)
parm:msi:supporto MSI (1 =abilita, 0 =disabilita, - 1 =automatico) (int)
...
Ad esempio, alcune delle opzioni disponibili puoi provare, ma NON farlo a meno che tu non capisca cosa stai facendo!
amdgpu.noretry=0
amdgpu.dc=1
Questi devono essere aggiunti alla riga di avvio del kernel nel menu di avvio. Con le distribuzioni Linux più recenti che utilizzano il bootloader GRUB2, la sequenza di comandi è la seguente:
- Apri /etc/default/grub in un editor di testo, come root o sudo (crea prima un backup)
- Aggiungi una o più opzioni amdgpu alla riga GRUB_CMDLINE_LINUX_DEFAULT.
- Salva il file e aggiorna la configurazione di GRUB con:
sudo update-grub
Oppure, su sistemi che non utilizzano lo script wrapper sopra:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Riavvia il sistema e verifica se il problema è stato risolto. Puoi controllare come si è avviato il sistema esaminando la riga di comando del kernel, o meglio, se si avvia bene con la batteria, ah ah!
cat /proc/cmdline
Ora, la grande domanda è:quali opzioni amdgpu dovresti aggiungere?
Non c'è una risposta semplice a questo, temo. Nella maggior parte dei casi, a meno di un'effettiva correzione del kernel/firmware, indovinerai, in base al messaggio di errore che vedi nel registro del kernel, e speri che l'opzione specifica possa fare il trucco. Questo perché i messaggi di errore sono spesso generici e senza esperienza nello stack grafico e nel driver particolare, non puoi davvero definirlo con una manciata di opzioni del modulo del kernel.
Apportare queste modifiche può potenzialmente portare a ulteriori problemi e complicazioni, motivo per cui non dovresti applicarle alla cieca o semplicemente copiare qualsiasi suggerimento da un forum. I miei test mostrano che nessuna opzione fa davvero una grande differenza. I due sopra elencati sono solo per riferimento. Tuttavia, se gli aggiornamenti del kernel non funzionano e devi essere in grado di utilizzare il laptop con l'alimentazione a batteria, immagino che tu non abbia nulla da perdere e potresti anche sperimentare e vedere cosa dà.
Conclusione
Eccoci. Si spera che il tuo laptop con grafica AMD che esegue Linux ora si stia comportando correttamente e non visualizzi più il problema dello schermo nero all'avvio durante l'utilizzo della batteria (o qualsiasi altro scenario). Il mio tutorial delinea tre approcci principali:aggiornamento del kernel, soluzione per l'utilizzo di energia e un po' di hackeraggio con i parametri del modulo del kernel, che sono rischiosi e molto probabilmente non ti daranno i migliori risultati, ma ehi.
Non mi piacciono questo tipo di problemi. Mi ricordano sempre quanto sia fragile Linux. Sì, funziona su tonnellate di hardware, ed è lodevole, ma è sempre al 95% o al 91%, mai al 100% fino in fondo. E questo è fastidioso. Bene, comunque, questo è tutto. Ora, vado al mio prossimo ostacolo di Tuxy. Ci vediamo in giro.