plantage avec noyau 6.2.x, 6.1.18 pas de problème
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
Pour info mon souci de freeze relaté dans le fil : https://forums.fedora-fr.org/d/73912-probl%C3%A8me-de-freeze-syst%C3%A8me est toujours présent avec le kernel 6.2.10-200. Je tourne donc avec le 6.1.15-200 et je n’ai pas de matos amd mais de l’intel, carte graphique NVIDIA et carte mère GigaByte
- Modifié
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
- Modifié
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.
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.
- Modifié
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.
kona68 Te voici quelques fondamentaux alors https://doc.fedora-fr.org/wiki/GRUB2_:_Les_bases_pour_Fedora .
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.