Bonjour à toutes et tous,

Mon 1er message sur le forum !

J’ai un lenovo T16, AMD ryzen 7 pro 6850u, avec une carte graphique partagée (iGPU).

Fedora 37 tourne nickel en 6.1.18, mais c’était pas avec certaines versions antérieures du noyau (j’avais des plantages graves du gpu, notamment liés à la lecture de vidéos, hard reboot nécessaire). Puis les soucis sont revenus depuis le passage aux versions 6.2 (que ce soit .7, .8, .9 ou 6.2.10 de ce jour).

J’ai donc conservé une version du 6.1.8 qui marche sans souci.

Les symptomes sur le 6.2: la souris comme l’accès clavier se figent (mais le son ou l’image continue); cela se produit sans même sollicité la vidéo (par ex en ouvrant thunderbird). J’arrive à sortir du blocage en fermant l’écran, puis en ressortant de veille et là la souris se débloque … avant de replanter peu après. Le plantage est moins grave que sous les versions antérieures à 6.1, où seul un arrêt par le bouton d’alim fonctionnait (pas même d’accès possible en ssh).

J’ai pas mal cherché sur le net: c’est un problème lié à amdgpu, pas seulement lié à la version 6.2 du noyau et qui dure depuis un bail; mas j’ai pas vraiment trouvé de solution (cela concerne de loin pas que les ryzen sous fedora, on trouve des posts sur arch, ubuntu, etc.

Par ex:

https://gitlab.freedesktop.org/drm/amd/-/issues/2113

https://gitlab.freedesktop.org/drm/amd/-/issues/2443

Log de mon dernier plantage en 6.2.10:

09:54:58 kernel: amdgpu 0000:04:00.0: [drm] \*ERROR\* [PLANE:55:plane-3] commit wait timed out
09:54:58 kernel: Freezing user space processes failed after 20.003 seconds (1 tasks refusing to freeze, wq_busy=0):
09:54:58 kernel: amdgpu 0000:04:00.0: [drm] \*ERROR\* [CRTC:67:crtc-0] commit wait timed out
09:54:58 kernel: amdgpu 0000:04:00.0: [drm] \*ERROR\* [PLANE:55:plane-3] commit wait timed out
09:54:58 kernel: Freezing user space processes failed after 20.003 seconds (1 tasks refusing to freeze, wq_busy=0):
09:54:58 kernel: amdgpu 0000:04:00.0: [drm] \*ERROR\* [CRTC:67:crtc-0] commit wait timed out

Ma question: j’arrive à vivre avec le noyau 6.1.18, mais c’est bancal et provisoire. Du reste, est-ce possible de garder ce noyau sur le moyen terme et d’avoir par ailleurs toutes les autres mises à jour de fedora 37 sans d’éventuels conflits (et quid lors du futur passage à F38 ?). Pour l’heure, j’ai adapté les paramètres de grub pour conserver plus que 3 noyaux par défaut.

Merci pour toute suggestions de solution !

Edit Nicosss : Correction des balises Markdown

  • Nicosss a répondu à ça.

    • kona68

    • Meilleure réponsesélectionnée par kona68

    Donc la solution qui marche chez moi est la solution avancée par naguam: éditer le fichier /etc/default/grub en ajoutant la ligne

    GRUB_CMDLINE_LINUX_DEFAULT=“amdgpu.dcdebugmask=0x10”

    puis

    sudo grub2-mkconfig -o /boot/grub2/grub.cfg

    kona68 Bienvenue !

    Tu es sous quel environnement de bureau ?
    Tu utilises Xorg ou Wayland ?

    Tu pourras trouver quelques éléments de réponses concernant la gestion de tes kernels dans la fin de cette discussion https://forums.fedora-fr.org/d/73912-probl%C3%A8me-de-freeze-syst%C3%A8me .

    Pour le passage en F38 tu pourras conserver ton kernel en .fc37 sans problème.

    Merci pour les liens vers les rapports de bugs.

    Attention à bien utiliser les balises Markdown pour les retours de commandes.

        Nicosss

        Merci pour l’accueil et la réponse.

        Je suis sous Wayland, et j’avais hésité de relancer le post cité, mais comme il était tagué résolu…

        Désolé, mais c’est quoi les balises Markdown ?

        Sinon, certains semblent résoudre des bugs ressemblant en ajoutant amdgpu.noretry=0 dans le fichier etc/default/grub

        La ligne à ajouter serait: GRUB_CMDLINE_LINUX_DEFAULT=“amdgpu.noretry=0”

        Puis sudo update-grub (même si uefi ?)

        https://forum.manjaro.org/t/freezing-on-amdgpu-driver-fixed/67753/1

        amdgpu.noretry, je sais pas à quoi cela correspond néanmoins…

            kona68 Alors en effet c’était une très bonne initiative que d’ouvrir ta propre discussion pour tout simplement éviter de mélanger tous les sujets. Ça évite ainsi d’avoir une lecture incompréhensible d’une discussion avec de multiples réponses sur différents problèmes.

            Wayland OK mais avec quel environnement de bureau, Gnome ou KDE je présume ?

            Pour les balises Markdown voici une explication https://fr.wikipedia.org/wiki/Markdown . Certaines des possibilités sont directement accessibles avec les boutons situés en bas de la zone de saisie. Sinon pour les retours de commandes il faut appliquer trois apostrophes inversées ` puis écrire nocode à la suite et aller à la ligne pour mettre le retour de la commande (prompt, commande complète et retour complet de celle-ci). Enfin il faudra aller à la ligne et mettre à nouveau trois apostrophes inversées.

            Avant de vouloir le mettre dans le fichier /etc/default/grub , il vaut mieux éditer les options de kernel au démarrage depuis le GRUB et ajouter cette option. Celle-ci ne sera appliquée que pour se démarrage, donc si ça pose un souci au moins elle ne sera pas écrite en dur et au prochain démarrage elle ne sera plus présente.

            Pour plus d’explications sur Grub2 je propose de consulter https://doc.fedora-fr.org/wiki/GRUB2_:_Les_bases_pour_Fedora .

            Pour l’explication de l’option passée au kernel, voir https://kernel.org/doc/html/latest/gpu/amdgpu/module-parameters.html .

                Nicosss

                Je suis sous gnome 43.4 (avec “battery threshold” activé, 75 à 85%).

                J’ai testé le démarrage avec le paramètre amdgpu.noretry=0 sous le 6.2.10

                Cela me semblait aller, mais au bout d’une heure, retour du plantage en regardant une vidéo (d’habitude cela plantait bien plus rapidement). Donc il me faut continuer à chercher. Lors du plantage, j’étais sur batterie, avec le mode “équilibré”.

                Note aussi que j’ai le dernier bios pour le thinkpad T16, installé pour tenter de résoudre le problème de plantage post 6.2

                Sinon, de manière générale, j’avoue être un peu surpris du caractère régressif d’une version de noyau par rapport à la précédente: comment les développeurs ne peuvent pas empêcher pareil bug sur une nouvelle version du noyau… pour une machine sous fedora, ou pour une rolling release, voir son système cassé et rendu inutilisable après une mise à jour du noyau, c’est plus que moyen.

                Merci encore pour ton aide.

                    kona68 comment les développeurs ne peuvent pas empêcher pareil bug sur une nouvelle version du noyau

                    C’est le propre d’une distribution qui veut toujours aller de l’avant. Parfois il y a un faux-pas.

                    Si tu veux des versions longue durée alors tourne-toi plutôt sur Rocky, Centos, RHEL ou similaires.

                      kona68 le système n’est pas inutilisable puisque tu as d’anciens noyaux. Attends la prochaine mise a jour noyau, ça sera probablement corrigé.

                          xylphute Attends la prochaine mise a jour noyau, ça sera probablement corrigé.

                          Il y a un bug d’ouvert ?

                              llaumgui en vrai je sais pas trop, mais au première lecture il y a pas mal de remontés de freezer de différents utilisateurs. Je spécule que ça du être fait.

                                  xylphute

                                  y a quand même eu plusieurs versions qui toutes posent ce problème depuis un moment (sous fedora, 6.2.7 à 6.2.10).

                                  Remonter les bugs à qui ? fedora, amd, ou les dév du kernel ? Des liens ?

                                  Je pense aussi qu’“ils” (qui ?) sont au courant…

                                  Tant que je peux continuer avec un noyau 6.1.18, pas de souci pour moi !

                                    En me basant sur du vécu, au nombre de dev et/ou utilisateur du kernel et de matériel amd, il y a forcément de la remonté de problème. On n’est pas sur quelque chose de marginal

                                    Hello,

                                    Je n’ai pas trop le temps de détailler plus, mais j’ai des soucis similaires sur mon thinkpad x13 gen3 amd avec une radeon 680M (APU).
                                    Il y a déjà des gens sur le coup mais je ne sais pas si ça va aboutir, notamment https://gitlab.freedesktop.org/drm/amd/-/issues/2453

                                    En gros sur certains modèles le panel self refresh (PSR) générait une sorte de flickering.
                                    Un “mauvais” fix un peu random a été appliqué pour corriger ce problème, cependant, ce fix a amené des crash en 6.2.8 ou quelque chose dans le genre.

                                    Temporairement un potentiel workaround peut être essayé: tenter de désactiver le PSR pour éviter que le kernel passe dans ce “code path”. (au coût d’une légère diminution de l’autonomie, mais c’est pas grand chose de ce que j’ai compris).

                                    Pour cela tentez d’ajouter le paramètre suivant dans la conf grub.

                                    amdgpu.dcdebugmask=0x10

                                    J’ai participé sur différentes issues sur le gitlab de freedesktop dont celle là, mais je n’ai pas “encore” trouvé d’autre issues sur ce problème en particulier hormis celles déjà liées à celle-ci (mais j’ai plus trop le temps de chercher en ce moment).

                                    AMD a tenté d’activer le panel self refresh par défaut à partir de rembrandt (gpu yellow carp) mais ils se prennent dans la tronche tous les problèmes que intel ont eu quand eux-même ont tentés d’ajouter cette feature. -> https://www.phoronix.com/news/AMDGPU-Linux-5.16-PSR#:\~:text=AMD Finally Enabling PSR By Default For Newer Hardware With Linux 5.16,-Written by Michael&text=With it getting late into,to instead on bug fixes.

                                    Sur ma machine je n’avais pas le soucis avant le 6.0 (flickering) car les kernels d’avant avaient juste le module amdgpu qui crashait avant de se restorer/reset sans le PSR. Il y a également un très long fil sur le sujet pour les t14s et x13 sur le forum officiel de lenovo (en anglais). https://forums.lenovo.com/t5/Fedora/Random-screen-flickering-on-T14s-Gen-3-AMD-in-Fedora-37/m-p/5198472?page=8#5941992

                                    Sinon, de manière générale, j’avoue être un peu surpris du caractère régressif d’une version de noyau par rapport à la précédente: comment les développeurs ne peuvent pas empêcher pareil bug sur une nouvelle version du noyau… pour une machine sous fedora, ou pour une rolling release, voir son système cassé et rendu inutilisable après une mise à jour du noyau, c’est plus que moyen.

                                    Apparemment les problèmes sont vraiment aléatoires en fonction du matériel (parfois même n’impactent pas pareil certains mêmes modèles)
                                    (Par exemple ça peut dépendre des dalles et Lenovo comme d’autres marques utilisent différents fournisseurs pour un même modèle).
                                    Du coup c’est difficile de reproduire les bugs et tous les devs n’ont pas tout les types de matériel sous le coude.

                                    En plus les drivers GPU sont parmi les drivers les plus complexes à développer, et avec parmi le plus de lignes de code dans le kernel.
                                    Ces deux facteurs augmentent le risque de regression, (et c’est encore pire sur du matériel récent comme ceux dont on parle ici, pas encore éprouvés)

                                    Ah et attention un autre type de crash peut arriver (à ne pas mélanger) en regardant des vidéos (firefox utilise le décodage gpu donc ça peut arriver) donc bien revérifier les logs à chaque crash.

                                    Voir https://gitlab.freedesktop.org/drm/amd/-/issues/2220

                                      naguam

                                      Merci pour les infos naguam. J’ai démarré sur le 6.2.10 avec le paramètre amdgpu.dcdebugmask=0x10et pas de plantage après 2h00, avec le même usage (alors que ça bugguait très rapidement sans), … Je croise les doigts et attends encore un peu avant de modifier le fichier /etc/default/grub.

                                      Une question: si on modifie ce fichier grub, cela va s’appliquer à tous les noyaux que j’utilise au démarrage, je suppose (donc à mon 6.1.18 comme au 6.2.10) ? Désolé, mais y a des fondamentaux gnu/linux qui me manquent.

                                          Modifier le fichier ne fait rien en tant que tel.

                                          Cependant appliquer les changements en utilisant grub2-mkconfig, ça va en effet régénérer les entrées pour tout les noyaux à partir d’un template.

                                          Il existe une solution pour donner des paramètres spécifiques à des entrées individuelles sans pour autant trifouiller manuellement dans les fichiers de grub : grubby.
                                          N’hésite pas à te renseigner sur le fonctionnement de grubby.

                                          6 jours plus tard

                                          En date du 22 avril, une mise à jour a proposé celle du firmware de amdgpu : amd-gpu-firmware noarch 20230404-149.fc38

                                          J’ai donc testé la suppression du paramètre du noyau ajouté précédemment comme solution: amdgpu.dcdebugmask=0x10

                                          Pour l’instant, tout semble fonctionner correctement sans plantage 😀

                                          N’hésite pas dans ce cas a faire un retour si tu considères que tu n’as plus de problème afin de marquer le sujet comme resolu. A ta convenance le temps d’éprouver que ça fonctionne bien.