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.

                                Bon, plantage de retour 😒 après quelques heures. Je remets l’option du noyau qui les a supprimé entièrement.

                                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