Reprise du message précédent :

Merci pour le lien. Ce serait donc la faute des pilotes Nvidia…
 

 
Pas ma faute s’ils l’ont publié quand la version suivante est sortie en amont !

Petite question : sur le PC fixe qui a une AMD Radeon R7 240, Linux 6.19 force l’usage du pilote « amdgpu » à la place de « radeon ». Mais ça provoque des bugs gênants (clignotements de l’écran et même crash qui ramène sur l’écran de connexion). J’ai remarqué que ça disparaissait quand je désactivais Xflux (oui, je continue à l’utiliser) et la rasterization GPU dans Vivaldi (mais ça cause une surconso CPU quand j’ouvre un onglet sur une instance Mastodon, et jusqu’à longtemps après que je l’ai fermé).
 
J’aimerais donc reprendre « radeon », mais si le wiki est ce qu’il est, il est pas super clair sur la marche à suivre dans ce sens-là (et j’ai pas envie de me louper…). Déjà, je vais faire un test en redémarrant demain sur le noyau LTS (qui vient de passer en 6.18.16, tiens…), histoire de voir quel pilote est chargé dans ces conditions.

La radeon R7 240 est de la génération Southern Islands, d'après le wiki Arch Linux le pilote amdgpu supporte les cartes de la génération Southern Islands et les générations suivantes :
 

 
https://wiki.archlinux.org/title/AMDGPU
 
Le wiki de gentoo confirme aussi que depuis le noyau 6.19 ta vieille carte graphique utilise maintenant le pilote amdgpu :
 

 
https://wiki.gentoo.org/wiki/AMDGPU
 
Il y avait cette page ancienne qui donnait le pilote amdgpu qu'à partir de la génération Volcanic Islands mais ça a dû changer depuis les versions récentes des noyaux Linux :
https://www.x.org/wiki/RadeonFeature/
 
regarde si tu as installé le paquet xf86-video-amdgpu et vulkan-radeon, le wiki Arch Linux conseille l'installation de x86-video-amdgpu pour les cartes de la génération Southern Islands comme la tienne, si tu utilises Xorg, ils indiquent que l'installation du paquet xf86-video-amdgpu peut résoudre des bugs liés à cette génération de cartes Southern Islands :
 

 
Je dirai de persévérer avec ce pilote amdgpu, car je n'aime pas l'idée d'aller à contre-courant de ce qui est normalement prévu pour ta carte graphique en terme de pilote, forcer l’utilisation d'un pilote non prévu pour ta carte graphique c'est risqué si tu utilises le dernier noyau Linux, il est probable que les quelques bugs que tu as seront bientôt résolus, avec une mise à jour du paquet mesa ou avec la prochaine version du noyau Linux, ou bien ces bugs peuvent être contournés via une option de configuration.
 
Si les bugs sont trop gênants : essaie de rétrograder le noyau Linux vers la version 6.18 ou 6.17, en attendant que les développeurs résolvent le problème, il y a peut-être un rapport de bug sur ce problème des cartes graphiques AMD de la génération Southern Islands sur le bugzilla de mesa ou du noyau Linux.

C'est un gars de Valve qui a fait ce changement, mais je ne sais pas s'il a toutes ces anciennes cartes pour tester. Il a l'air sympa, je pense qu'il prendrait un rapport de bog la dessus serieusement.

Ça, c’est la théorie. Dans les faits, ça ne marche pas aussi bien qu’on veut le croire, dans mon cas. D’où mon précédent message.
 

Phoronix et OMG! Ubuntu ont suffisamment dit que c’était un changement effectif depuis le 6.19 pour que ce ne soit plus à considérer comme une possibilité, oui.
 

Pas besoin de vérifier : je sais que c’est « xf86-video-ati » que j’ai installé quand j’ai mis cette CG, en janvier 2021… Mais peut-être que je peux ajouter « xf86-video-amdgpu ». Ça pose pas de problème, d’avoir les deux ?
 

Bah, pour l’instant, on n’en est pas là… Mais j’ai vu sur le forum que d’autres avaient aussi des problèmes de crash d’AMDGPU depuis le 6.18.
 
Après, pour le côté « contre-courant »… La config date de 2009 (ou fin 2008, en vrai) ; les seuls composants non d’origine sont la CG et l’alimentation (en 2021)… Si c’est la question de la prise en charge du matos, je pense pas qu’être sur la toute dernière version soit primordial. Quant aux corrections de bugs…
 

Bah, une déconnexion brutale de la session et un retour à la mire de connexion, je sais pas pour toi, mais moi, je classe en effet ça dans le « trop gênant ».
 
Donc, oui, ce matin, j’ai démarré sur le 6.12 LTS (qui, lui, emploie bien « radeon » et « radeonsi » ; pas encore fait la MAJ vers le 6.18 LTS, que je soupçonne d’autres problèmes liés à l’affichage, mais plus simples à éviter), et je poursuivrai mes essais dans l’après-midi.
 

Pour des infos plus techniques, voilà ce que journalctl m’a pondu lors des deux crashs (à 14h30 et 16h10) :
 

Si vous pouvez en tirer quelque chose…

Bonjour  
Pour avoir un rappel des mise à jour j'ai installé apdatifier : https://store.kde.org/p/2135796
C'est cool, ça marche super bien mais ça me fait une grosse verrue sur le bureau.
Je cherche plutôt une simple icone de notification, vous me conseillez quoi ?
Merci

Sur cachy on a arch-update installé avec arch-update sys tray applet pour les notifs
(enfin là je vois que tout ça a été renommé en cachy-update... c'est très récent, ça doit être un fork maison)

 
Merci, j'ai trouvé le github : https://github.com/Antiz96/arch-update
 
Sinon je viens de voir que ça doit être possible aussi avec apdatifier :

https://store.kde.org/p/2135796

Sur PC portable identique Debian fait carrément des mises à jour firmware, j’étais étonné.
 
Je suppose que sous Arch il y a bien quelque chose qui Check ça ?

 
Désinstalle x86-video-ati et installe à la place x86-video-amdgpu, puis tu redémarres pour voir si les bugs ont disparus,
 
autre test : si le problème n'est pas résolu alors désinstalle tous les paquets en x86-video-*, y compris celui en amdgpu, cela utilisera alors un pilote intégré, comme ça on aura testé tous les cas de figure installation/absence de paquet x86-video*.
 
Tu peux aussi regarder si en mode wayland les bugs disparaissent.
 
Trouver un rapport de bug pour y ajouter ton cas aidera et incitera les développeurs à corriger au plus vite ce problème.

@trit' :  
La soluce est donnée dans la log  

 
Tu rajoutes ça dans la ligne de démarrage du noyau dans la config Grub et hop !

Donc, faut éviter les deux ensemble. Je note.
 

Y en a qu’un, de toute façon…
 

XFCE, donc pas de Wayland (sauf de façon très expérimentale, mais j’y toucherai pas sur un ordi utilisé aussi par les parents).
 

Il y a un fil sur le forum, je songeais à y apporter mon petit gravier…
 

J’ai vu cette ligne en relisant le log, mais je voulais m’assurer que c’était ça et pas autre chose à y mettre.
 
Mais je pense que je vais plutôt laisser le week-end passer avant d’y retoucher. Là, pour l’instant, je vois que tout est de nouveau d’équerre en 6.12.75 (et pour cause…), je vais laisser en l’état dans l’immédiat.
 
Merci à vous deux.

La mauvaise petite surprise, en faisant les MAJ sur le PC portable avant d’éteindre pour la nuit : au moment de la génération des initramfs de la nouvelle version 6.18.16 de « linux-lts », une erreur qui disait qu’il n’y avait plus de place sur le disque !
 
OK, nous avons ici affaire à une installation en MBR avec une partition « /boot » séparée de 512 Mo (soit 503 Mio), avec dedans GRUB et les deux images noyau « linux » et « linux-lts », et chacune ayant son initramfs « default » (dans les 45 Mio) et « fallback » (dans les 180 Mio).
 
Ah, mais les « fallback » ne sont plus censées être générées par défaut, non ? Bah, s’il est vrai qu’elles ne le sont plus sur la VM minimale que j’ai faite l’an dernier (mais avant ce changement), rien n’a changé pour les deux installations faites en dur, respectivement en 2016 (portable) et 2017 (fixe). Et sur ce dernier, en pré-MAJ, je vois que « /boot » n’a plus que 43 Mio de libres…
 
Donc, dans l’immédiat, j’ai dégagé le noyau LTS du portable (grub.cfg régénéré dans la foulée, évidemment) et vais voir à quoi ressemble le fichier « linux.preset » de la VM et modifier ceux des autres ordis en conséquence. Pour info, celui des autres machines date de 2023.
 
La question est : suffira-t-il simplement, ensuite, de refaire une passe de « mkinitcpio -p linux linux-lts » pour dégager les images « fallback » et redonner un peu d’air à ces partitions ? Et quid du fichier « linux-lts.preset.pacsave » ? Je peux le virer et il en régénérera un autre quand je le réinstallerai ?
 
À noter que, justement, sur le fixe, je suis actuellement sur le noyau LTS à cause de l’autre souci de ce week-end… Lui, je pense que je vais d’abord devoir rajouter les instructions noyau au démarrage, puis procéder ensuite à la présente manip… Ça va être simple, je sens !
 
Rendez-moi l’époque où j’avais qu’à faire un « time yay », Entrée, Entrée et zou, c’est fini !
 
EDIT : fichier de la VM récupéré et comparé avec celui du portable. Mais je vois d’emblée une bizarrerie :
 
Fichier du portable :

Fichier de la VM :

La ligne « ALL_config="/etc/mkinitcpio.conf" » est commentée sur la « nouvelle version » du fichier. Ça a de l’importance ? A priori, non, puisque les MAJ du noyau sur la VM se font aussi bien qu’ailleurs…
 
Bon, je commencerai par voir comment ça se passe en réinstallant le LTS et aviserai ensuite.

Le fichier linux.preset que j'utilise sur le PC fixe dont l'installation d'Arch Linux remonte à 2013 :
 

 
le partitionnement est de type MBR,
 
si ta partition /boot est trop petite alors tu peux l'agrandir avec gparted-livecd, en téléchargeant l'ISO pour la mettre sur une clé USB :
https://gparted.org/livecd.php
 
un tutoriel :
https://www.malekal.com/gparted-red [...] de-disque/
 
Il y a un petit risque de perte de données, il est conseillé de sauvegarder avant les données les plus précieuses.
 
Si tu ne veux pas prendre de risques alors tu peux essayer d'optimiser en installant qu'un seul noyau, ou 2 noyaux mais sans la version fallback (tu devras peut-être supprimer à la main le fichier image fallback du noyau Linux).
 
Tu peux aussi compiler un noyau avec uniquement les modules nécessaires (ceux utilisés par ton PC), le noyau sera alors très petit en taille, il faut générer un fichier contenant la liste des modules utilisés par ton PC portable, puis l'utiliser pour la compilation, la compilation peut se faire sur un autre PC beaucoup plus puissant, si le CPU du PC portable est trop lent pour la compilation du noyau Linux.
 
Sur un CPU Intel Core 2 quad Q9650 3 Ghz de 2009 je mets 30 minutes pour compiler un noyau Linux avec que les modules nécessaires au matériel du PC, sur un CPU plus récent avec plein de coeurs ça devrait être encore plus rapide, peut-être 15 minutes en utilisant 8 coeurs et un SSD plutôt qu'un disque dur pour les opérations de lecture et écriture des fichiers de compilation, certains utilisent un disque virtuel en mémoire vive pour aller encore plus vite pour la compilation.
 
On peut se servir du PKGBUILD du noyau Linux classique (ou LTS), pour changer son nom en "linux-custom" ou "linux-lts-custom", il sera alors ajouté dans le menu de Grub en compagnie des noyaux Linux existants, il sera de très petite taille si tu compiles que les modules du noyau utilisés par le matériel de ton PC :
 

 
https://wiki.archlinux.org/title/Ke [...] ild_system

Curieux que ta ligne « ALL_config » soit commentée aussi, alors qu’elle l’est pas chez moi (et je me souviens pas avoir touché à ces fichiers)… Bref.
 
Je pensais réinstaller le noyau LTS sur le portable (avec un nouveau fichier « linux-lts.preset » tout neuf qu’il devrait apporter, il ne devrait générer que l’initramfs « default », non ? Ça devrait laisser de la place sur /boot), et laisser le noyau non LTS avec les deux, au moins dans un premier temps.

Oui ça devrait générer que la version "default", si tu configures le fichier linux-lts.preset avec cette ligne en retirant "fallback" :