Récemment, j'ai rencontré un tout nouveau problème lié au matériel avec une distribution Linux. Dans Linux Mint 20.2, lors du démarrage sur batterie, c'est-à-dire sans jus de prise murale, le processus de démarrage s'arrêtait à un moment donné, avec un écran noir qui ne répondait pas. La seule solution consiste à redémarrer ou à allumer l'hôte avec le chargeur branché.
Ce qui est intéressant, c'est que cela s'est produit sur un ordinateur portable IdeaPad 3 relativement nouveau avec des graphiques AMD Vega 8. Et cela m'a beaucoup ennuyé, car il semble toujours y avoir un problème avec le matériel. Sans fil sur cette machine, graphiques sur celle-ci, contrôle E/S ici, caméra là, et ainsi de suite. Toujours des problèmes, toujours des excuses. Eh bien, voyons ce que nous pouvons faire ici et comment résoudre ce problème.
Problème plus en détail
J'ai rencontré le problème avec Linux Mint. Mais je soupçonne que le problème affecte une base beaucoup plus large. En effet, si vous recherchez "écran noir de démarrage AMD", vous obtiendrez des tonnes de résultats pour les fils de discussion du forum, qu'ils soient Ubuntu, Mint, Arch, Manjaro ou Gentoo, datant de 2019, avec des tonnes de recommandations et très peu de solutions réelles . Pourquoi? Parce que la résolution des problèmes avec les pilotes demande de l'expertise, et si votre noyau et/ou vos pilotes n'offrent pas le bon type de fonctionnalité, vous ne pouvez pas faire grand-chose. Cela met également en lumière la question des pilotes open source par rapport aux pilotes open source, comme si cela faisait une différence. Ce n'est pas le cas, car l'expertise est l'expertise.
Mis à part le mini-diatribe, la machine IdeaPad 3 a une configuration à triple démarrage, comprenant également MX-21 KDE et Windows. Étant donné que ces deux autres systèmes fonctionnent sans aucun problème, je pourrais exclure un problème matériel et me concentrer sur ce qui est spécifiquement faux (et différent) avec la séquence de démarrage de Mint.
À cette fin, j'ai pris les fichiers journaux dmesg, kern.log, X.org.log et système de Mint et MX-21 et les ai comparés, côte à côte, en faisant des différences réelles. La seule vraie différence se trouve dans le journal du noyau, où Mint arrête de démarrer tandis que l'autre distribution continue joyeusement. L'erreur se lit comme suit :
...
kernel :[] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information :process Xorg pid 790 thread Xorg:cs0 pid 824
kernel :[] amdgpu 0000:03:00.0 :La réinitialisation du GPU commence !
kernel :[] amdgpu 0000:03:00.0 :réinitialisation du GPU réussie, tentative de reprise
kernel :[] [drm] PCIE GART de 1024M activé (tableau à 0x000000F400900000).
kernel :[] [drm] PSP reprend...
kernel :[] [drm] reserve 0x400000 from 0xf47f800000 for PSP TMR
kernel :[] [drm] psp command failed and l'état de la réponse est (0x7)
kernel :[] [drm] Décodage et encodage VCN initialisés avec succès (sous le mode SPG).
kernel :[] amdgpu 0000:03:00.0 : ring gfx utilise la VM inv eng 0 sur le hub 0
Finalement, la réinitialisation du GPU réussit, mais cela n'aide pas. L'écran reste noir. Maintenant, laissez-moi vous montrer comment vous pouvez résoudre ou contourner le problème. Nous avons quelques options à notre disposition.
Solutions
OK, alors voici ce que vous pouvez faire :
Installer un nouveau noyau (si disponible)
Mettez à niveau le noyau du système et/ou le micrologiciel. Dans Linux Mint, qui épingle normalement les noyaux, vous pouvez en télécharger manuellement un nouveau via l'utilitaire de mise à jour du système. Il vous avertira, puis vous pourrez sélectionner la version souhaitée et la configurer. Pour Mint 20.2 Uma, vous pouvez passer du noyau 5.4 au noyau 5.13.
Lorsque j'ai installé le nouveau noyau et examiné la sortie de configuration, j'ai également remarqué un ensemble de messages d'avertissement lors de la génération du fichier initramfs :
...
W :Possible firmware manquant /lib/firmware/amdgpu/vangogh_vcn.bin pour le module amdgpu
W :Possible manquant firmware /lib/firmware/amdgpu/navy_flounder_vcn.bin pour le module amdgpu
W :Possible firmware manquant /lib/firmware/amdgpu/navi12_vcn.bin pour le module amdgpu
W :Possible manquant firmware /lib/firmware/amdgpu/aldebaran_vcn.bin pour le module amdgpu
Vous pouvez les ignorer SI votre architecture GPU AMD n'apparaît pas dans cette liste. Dans mon cas, Vega 8 était correctement pris en charge (c'est-à-dire pas dans cette liste). Comment sait-on ? Eh bien, vous pouvez exécuter la commande lspci -v, qui listera tous vos différents composants matériels. Vous avez besoin de l'entrée qui correspond au bon pilote de noyau utilisé, dans ce cas amdpu.
03:00.0 Contrôleur compatible VGA :Advanced Micro Devices, Inc. [AMD/ATI] Picasso (rév c2) (prog-if 00 [contrôleur VGA])
Sous-système :Lenovo Picasso
De cette façon, j'ai découvert que mes graphismes Vega 8 correspondent en fait à un modèle d'architecture appelé Picasso. Je suppose que cela explique les noms utilisés, en général. Cette sortie n'est qu'un bruit désordonné vous informant que de nouveaux noyaux ne prennent pas en charge certains modèles de GPU. Encore une fois, cela ouvre une question plus large sur la rétrocompatibilité Linux et autres, mais nous n'allons pas en discuter maintenant. Redémarrez, et cela devrait, espérons-le, faire le travail.
Démarrez l'hôte avec l'alimentation branchée
C'est ennuyeux, mais c'est une solution de contournement simple si vous n'êtes pas à l'aise pour apporter des modifications au système ou si vous ne voulez rien faire de spécial jusqu'à ce que votre distribution Linux résolve le problème. Cependant, le problème met en évidence un (petit) inconvénient de la politique du noyau de Mint et un phénomène générique et plus large de prise en charge matérielle sous Linux. Parce que, si votre distribution n'a pas de noyau mis à jour disponible, vous ne pouvez pas faire grand-chose.
La raison pour laquelle cette "astuce" fonctionne est qu'un système à pleine puissance (par opposition à l'alimentation par batterie) utilise différents profils d'alimentation. Si vous êtes vraiment averti, vous pouvez jouer avec les options de performances d'alimentation de votre BIOS, si elles sont disponibles, ou modifier les paramètres d'alimentation du GPU, mais cela n'est qu'une mesure provisoire.
Modifier les paramètres de démarrage
Poursuivant ce que j'ai mentionné juste plus tôt, vous pouvez démarrer le système en transmettant une gamme de paramètres différents au module de noyau AMD GPU (amdgpu). Vous pouvez vérifier le type de paramètres et d'options pris en charge par le module en exécutant la commande modinfo :
modinfo amdgpu
nom de fichier :/lib/modules/5.13.0-22-generic/kernel/drivers/gpu/drm/amd/amdgpu
/amdgpu.ko
licence :GPL et droits supplémentaires
description :AMD GPU
auteur :AMD linux driver team
...
parm :audio:Audio enable (-1 =auto, 0 =disable, 1 =activer) (int)
parm :disp_priority :Priorité d'affichage (0 =auto, 1 =normal, 2 =élevé) (int)
parm :hw_i2c:hw i2c engine enable (0 =disable) ( int)
parm :pcie_gen2:PCIE Gen2 mode (-1 =auto, 0 =désactiver, 1 =activer) (int)
parm :msi:MSI support (1 =activer, 0 =désactiver, - 1 =auto) (entier)
Par exemple, vous pouvez essayer certaines des options disponibles - mais ne le faites PAS à moins que vous ne compreniez ce que vous faites !
amdgpu.noretry=0
amdgpu.dc=1
Ceux-ci doivent être ajoutés à la ligne de démarrage du noyau dans le menu de démarrage. Avec les distributions Linux les plus récentes qui utilisent le chargeur de démarrage GRUB2, la séquence de commandes est la suivante :
- Ouvrir /etc/default/grub dans un éditeur de texte, en tant que root ou sudo (créer une sauvegarde au préalable)
- Ajoutez une ou plusieurs options amdgpu à la ligne GRUB_CMDLINE_LINUX_DEFAULT.
- Enregistrez le fichier et mettez à jour la configuration GRUB avec :
sudo update-grub
Ou, sur les systèmes qui n'utilisent pas le script wrapper ci-dessus :
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Redémarrez votre système et voyez si votre problème est résolu. Vous pouvez vérifier comment le système a démarré en examinant la ligne de commande du noyau - ou plutôt, s'il démarre correctement sur batterie, ha ha !
chat /proc/cmdline
Maintenant, la grande question est, quelles options amdgpu devriez-vous ajouter ?
Il n'y a pas de réponse simple à cela, j'en ai peur. Dans la plupart des cas, à moins d'un correctif noyau/firmware réel, vous devinerez, en vous basant sur le message d'erreur que vous voyez dans le journal du noyau, et espérez que l'option spécifique peut faire l'affaire. En effet, les messages d'erreur sont souvent génériques, et sans expertise dans la pile graphique et le pilote particulier, vous ne pouvez pas vraiment le cerner avec une poignée d'options de module du noyau.
Faire ces modifications peut potentiellement entraîner des problèmes et des complications supplémentaires, c'est pourquoi vous ne devriez pas les appliquer aveuglément, ou simplement copier n'importe quelle suggestion d'un forum. Mes tests montrent qu'aucune option ne fait vraiment une grande différence. Les deux énumérés ci-dessus sont juste pour référence. Pourtant, si les mises à jour du noyau ne fonctionnent pas et que vous devez pouvoir utiliser l'ordinateur portable sur batterie, alors je suppose que vous n'avez rien à perdre, et vous pourriez aussi bien expérimenter et voir ce que ça donne.
Conclusion
Nous y voilà. Espérons que votre ordinateur portable graphique AMD exécutant Linux se comporte maintenant correctement et que vous ne voyez plus le problème d'écran noir au démarrage lors de l'utilisation de la batterie (ou de tout autre scénario). Mon didacticiel décrit trois approches principales :la mise à niveau du noyau, la solution de contournement de l'utilisation de l'alimentation et certains piratages avec les paramètres du module du noyau, qui sont risqués et ne vous donneront probablement pas les meilleurs résultats, mais bon.
Je n'aime pas ce genre de problèmes. Ils me rappellent toujours à quel point Linux est fragile. Oui, il fonctionne sur des tonnes de matériel, et c'est louable, mais c'est toujours 95 % ou 91 %, jamais 100 % de bout en bout. Et c'est ennuyeux. Bon, de toute façon, c'est ça. Maintenant, je vais à mon prochain obstacle Tuxy. À bientôt.