Bonjour,
Mon PC étant assez âgé (i5-2500k et Nvidia GTX550Ti) j'utilisais jusqu'à maintenant le pilote proprio nvidia 390.157. Tout fonctionnait parfaitement. Ce pilote n'étant plus maintenu, pas compatible avec kernel 6.4 et retiré de
debian testing j'ai donc décidé de passer à Nouveau.
Mais depuis j'ai régulièrement des freezes et j'ai des doutes sur le fait que
ma config soit correcte.
Pour passer du pilote proprio à Nouveau j'ai donc supprimé tous les paquets nvidia-* et libnvidia*
J'ai supprimé le xorg.conf.
J'ai essayé de suivre cette page (qui ne semble pas à jour) pour récupérer les
firmware du pilote 390.157.
J'ai réussi, après quelques modif du script[...]
extract_firmware.py, à récupérer les fichiers suivant:
Le 31/07/2023 à 00:20, Gaëtan Perrier a écrit :
Bonjour,
Mon PC étant assez âgé (i5-2500k et Nvidia GTX550Ti) j'utilisais jusqu'Ã
maintenant le pilote proprio nvidia 390.157. Tout fonctionnait parfaitement.
Ce pilote n'étant plus maintenu, pas compatible avec kernel 6.4 et retiré de
debian testing j'ai donc décidé de passer à Nouveau.
apparemment un autre possibilité serait de garder le pilote proprio en passant de testing à Sid, le pilote proprio y étant toujours disponible car des modifications mineures ont été apportées pour que ça puisse être
construit avec les noyaux récents, si j'ai bien suivi.
Après c'est à toi de voir, chacun a une perception différente. Perso, pour moi Debian c'est intéressant en Stable. Mais j'ai déjà joué avec Testing et Sid par le passé et même Sid+experimental récemment. Je préférerais suivre Sid que testing, à titre perso, toujours.
Mais depuis j'ai régulièrement des freezes et j'ai des doutes sur le fait que
ma config soit correcte.
Pour passer du pilote proprio à Nouveau j'ai donc supprimé tous les paquets
nvidia-* et libnvidia*
J'ai supprimé le xorg.conf.
t'as supprimé ou purgé? Si tu as seulement supprimé, fais un purge des mêmes paquets, ça peut aider
J'ai essayé de suivre cette page (qui ne semble pas à jour) pour récupérer
les
firmware du pilote 390.157.
quelle page?
J'ai réussi, après quelques modif du script[...]
extract_firmware.py, à récupérer les fichiers suivant:
tu as essayé avec simplement les firmwares de testing?
firmware-misc-nonfree firmware-nvidia-gsp ou firmware-nvidia-tesla-gsp
Mon PC étant assez âgé (i5-2500k et Nvidia GTX550Ti) j'utilisais jusqu'à maintenant le pilote proprio nvidia 390.157. Tout fonctionnait parfaitement. Ce pilote n'étant plus maintenu, pas compatible avec kernel 6.4 et retiré de debian testing j'ai donc décidé de passer à Nouveau.
Par contre depuis j'ai constaté que si je mets un fichier xorg.cong basique:
Section "Device"
Identifier "MyGPU"
Driver "nouveau"
EndSection
Le support des décodeurs en user est ok ...
Pour l'instant ça semble tourner. Reste à voir si j'ai toujours des freeze ou
pas ...
Le 31/07/2023 à 11:18, Gaëtan Perrier a écrit :
[...]
Par contre depuis j'ai constaté que si je mets un fichier xorg.cong basique:
Section "Device"
        Identifier      "MyGPU"         Driver          "nouveau"
EndSection
Le support des décodeurs en user est ok ...
Donc problème résolu ou il reste un autre truc qui ne marche pas (j'ai
pas épluché les sorties de commandes que tu as citées) ?
Pas eu besoin d'attendre longtemps :(
Freeze juste après l'envoi du message précédent.
Rien dans /var/log/syslog à part une série de ^@
Le 31 juillet 2023 didier gaumet a écrit :
Tu es sous Wayland ou Xorg (et tu es bien sous Systemd pax SysV)?
Pour Wayland il faudra fouiller dans les résultats de journalctl, pour Xorg >> lancé par un utilisateur avec un DE il faudra regarder le contenu de
~/.xsession-errors, pour Xorg lancé par un utilisateur sans DE, je ne me
souviens plus, c'est peut-être plutôt ~/.xinitquelquechose (pas sûr). Pour un
Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou
/var/log/Xorg.0.log.
Si on modifie startx, ~/.xsession, etc, on peut avoir les logs ailleurs
mais sinon on les a dans ~/.local/share/xorg/Xorg.0.log
Le 31/07/2023 à 14:00, didier gaumet a écrit :
[...]
Pour un Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou[...]
/var/log/Xorg.0.log.
(je suis pénible à ne pas me relire soigneusement):
Pour un Xorg lancé par root ce devrait être /var/log/Xorg.log ou /var/log/Xorg.0.log.
Le 31 juillet 2023 Michel a écrit :
Si on modifie startx, ~/.xsession, etc, on peut avoir les logs ailleurs
mais sinon on les a dans ~/.local/share/xorg/Xorg.0.log
Sur ma debian de base, les logs sont bien dans /var/log/Xorg.0.log par
défaut, sans modification de startx ou de ~/.xsession ...
Ce ne serait pas parce que Xorg est lancé en root ? Par défaut les users n'ont pas accès à /var/log. Vérifie /etc/X11/Xwrapper.config qui doit avoir needs_root_rights=no (du moins si ta carte graphique le permet).
Le 1 août 2023 Michel a écrit :
Sur ma debian de base, les logs sont bien dans /var/log/Xorg.0.log par >>>> défaut, sans modification de startx ou de ~/.xsession ...
Ce ne serait pas parce que Xorg est lancé en root ? Par défaut les users >>> n'ont pas accès à /var/log. Vérifie /etc/X11/Xwrapper.config qui doit >>> avoir needs_root_rights=no (du moins si ta carte graphique le permet).
Non, j'ai seulement une ligne non commentée:
allowed_users=console
Ok donc tu dois tourner en root. Vérifie avec un ps aux | grep Xorg
et si Xorg est en root ajoute needs_root_rights=no dans /etc/X11/Xwrapper.config. C'est mieux pour la sécurité.
Mais ça peut coincer si tu as une carte graphique qui requiert les droits root (c'est rare mais il y en a).
Je viens de faire le test, en ajoutant needs_root_rights=no à la fin du fichier /etc/X11/Xwrapper.config.
Après un arrêt puis un démarrage de la machine, Xorg est toujours lancé en root. Ma configuration était d'origine et non modifiée ( Xorg n'est
pas lancé depuis une console, mais depuis l'écran graphique de connexion ).
Le 31 juillet 2023 didier gaumet a écrit :
Tu es sous Wayland ou Xorg (et tu es bien sous Systemd pax SysV)?
Pour Wayland il faudra fouiller dans les résultats de journalctl, pour Xorg
lancé par un utilisateur avec un DE il faudra regarder le contenu de ~/.xsession-errors, pour Xorg lancé par un utilisateur sans DE, je ne me souviens plus, c'est peut-être plutôt ~/.xinitquelquechose (pas sûr). Pour
un
Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou /var/log/Xorg.0.log.
Si on modifie startx, ~/.xsession, etc, on peut avoir les logs ailleurs
mais sinon on les a dans ~/.local/share/xorg/Xorg.0.log
Ce ne serait pas parce que Xorg est lancé en root ?
Par défaut les users n'ont pas accès à /var/log.
Vérifie /etc/X11/Xwrapper.config qui doit
avoir needs_root_rights=no (du moins si ta carte graphique le permet).
Le 01/08/2023 à 09:22, Michel a écrit :
Je viens de faire le test, en ajoutant needs_root_rights=no à la fin du
fichier /etc/X11/Xwrapper.config.
Après un arrêt puis un démarrage de la machine, Xorg est toujours lancé >> en root. Ma configuration était d'origine et non modifiée ( Xorg n'est
pas lancé depuis une console, mais depuis l'écran graphique de connexion ).
certains display managers ("l'écran graphique de connexion") ne
supportent pas le mode rootless. Parmi les display managers actuellement maintenus, GDM et SDDM acceptent le mode rootless, LightDM et XDM ne l'accpetent pas, TDM (le DM de Trinity), je ne sais pas mais je suppose
que non car il doit être dérivé de KDM, abandonné: https://wiki.archlinux.org/title/Xorg#Rootless_Xorg
Le lundi 31 juillet 2023 à 14:00 +0200, didier gaumet a écrit :
Je suis sous xorg et systemd
Pour Wayland il faudra fouiller dans les résultats de journalctl, pour
Xorg lancé par un utilisateur avec un DE il faudra regarder le contenu
de ~/.xsession-errors, pour Xorg lancé par un utilisateur sans DE, je ne
me souviens plus, c'est peut-être plutôt ~/.xinitquelquechose (pas sûr).
Rien de tel dans mon rép user
Le 31 juillet 2023 Michel a écrit :
Si on modifie startx, ~/.xsession, etc, on peut avoir les logs ailleurs mais sinon on les a dans ~/.local/share/xorg/Xorg.0.log
Sur ma debian de base, les logs sont bien dans /var/log/Xorg.0.log par défaut, sans modification de startx ou de ~/.xsession ...
Ce ne serait pas parce que Xorg est lancé en root ? Par défaut les users n'ont pas accès à /var/log. Vérifie /etc/X11/Xwrapper.config qui doit avoir needs_root_rights=no (du moins si ta carte graphique le permet).
tu utilises gdm avec Systemd donc je crois que tu trouveras ses messages (ceux de gdm) via journalctl:
https://wiki.archlinux.org/title/Xorg#General
Chez moi ça tourne bien en user sans avoir la ligne needs_root_rights=no
~$ ps aux | grep Xorg
gpe 3127 2.5 0.6 460772 109108 tty2 Sl+ 11:44 0:27 /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority - nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3
Le 31/07/2023 à 14:00, didier gaumet a écrit :
Le 31/07/2023 à 12:49, Gaëtan Perrier a écrit :
Pas eu besoin d'attendre longtemps :(
Freeze juste après l'envoi du message précédent.
Rien dans /var/log/syslog à part une série de ^@
Tu es sous Wayland ou Xorg (et tu es bien sous Systemd pax SysV)?
Pour Wayland il faudra fouiller dans les résultats de journalctl, pour Xorg lancé par un utilisateur avec un DE il faudra regarder le contenu
de ~/.xsession-errors, pour Xorg lancé par un utilisateur sans DE, je
ne me souviens plus, c'est peut-être plutôt ~/.xinitquelquechose (pas sûr). Pour un Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou /var/log/Xorg.0.log.
Pour tous les fichiers d'erreur Xorg, de mémoire il faut chercher les chaînes EE pour les erreurs et WW pour les avertissements, le reste je crois que c'est principalement II pour info (me rappelle pas bien)
Et si tu veux vraiment faire de la plongée (je ne sais plus qui nous parlait de plongée récemment sur cette liste), tu peux essayer de debugger tout ça: https://x.org/wiki/Development/Documentation/ServerDebugging/
En testing ça fait plusieurs mois que les logs users après sddm sont
dans journal, plus dans .xsession-errors
Le 01/08/2023 à 12:04, Gaëtan Perrier a écrit :
Chez moi ça tourne bien en user sans avoir la ligne needs_root_rights=no
~$ ps aux | grep Xorg
gpe        3127 2.5 0.6 460772 109108 tty2   Sl+ 11:44  0:27
/usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority - nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3
tu utilises gdm avec Systemd donc je crois que tu trouveras ses messages (ceux de gdm) via journalctl:
https://wiki.archlinux.org/title/Xorg#General
apparemment (vu que JSON et moi ça fait deux) ce pourrait être un
argument vide passé en paramètre qui déclencherait cette erreur. Regarde éventuellement dans les lignes précédentes si tu vois où / dans quoi ça a lieu (plus précisément que gnome-shell)
Ah je ne savais pas mais je viens de regarder dedans et rien au niveau du freeze d'hier à part des quantités de log
gnome-shell[3330]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data
Mais y en a plein en permanence de ces logs.
Gaëtan
Le lundi 31 juillet 2023 à 12:42 +0200, Gaëtan Perrier a écrit :
Pour l'instant ça semble tourner. Reste à voir si j'ai toujours des freeze
ou
pas ...
Pas eu besoin d'attendre longtemps :(
Freeze juste après l'envoi du message précédent.
Rien dans /var/log/syslog à part une série de ^@
Gaëtan
Concernant les freeze j'ai avancé.
Ce soir pendant le freeze je me suis connecté en ssh depuis une autre machine
et c'est gnome-shell qui freeze en consommant 100% d'un cœur. Mais les fois d'avant je n'avais pas été assez patient parce que là en attendant je me suis
aperçu que ça defreeze !
Et dans journalctl j'ai cette trace qui est apparue à ce moment là :
geoclue[46380]: Service not used for 60 seconds. Shutting down..
systemd[1]: geoclue.service: Deactivated successfully.
Et 60 s ce n'est pas impossible que ce soit la durée du freeze ...
(pure supposition) Ce qui voudrait dire que si on veut éviter lesennuis avec ces cartes à problème (avec Nouveau), il faudrait s'en
J'ai lu en diagonale vu que c'est long et que je n'ai pas les
compétences pour analyser ça correctement
- (je dis peut-être n'importe quoi sur ce coup) potentiellement
peut-être que les messages sur Nouveau après le reboot proviennent,
non
pas d'un fonctionnement perfectible en condition normale mais d'une tentative de récupération suite au crash (peut-être que la carte
avait
tenté une économie d'énergie avant plantage et que le système cherche
Ã
remettre en condition antérieure. J'en sais rien.
- par contre, vérifier que le pilote Nouveau gère bien l'énergie de
ta
carte graphique (ton modèle) parce que de mémoire, Nouveau ne gère
pas
correctement ou pas du tout certaines cartes pour la gestion
d'énergie.
(pure supposition) Ce qui voudrait dire que si on veut éviter lesennuis avec ces cartes à problème (avec Nouveau), il faudrait s'en
servir à l'ancienne (desktop pas laptop, jamais de suspend/hibernate,
Ã
paramétrer dans le DE)
- en fait aussi, tu utilises Gnome, non? tu peux peut-être utiliser
Gnome Wayland au lieu de Gnome X11? Wayland c'est le fonctionnement
par
défaut ed nos jours et je crois que les anciens problèmes du genre RDP/Wayland et ce genre de truc c'est plus ou moins résolu.
- kworker de ce que je comprends, c'est des processus attachés à des machins en espace noyau plutôt qu'utilisateur (pas sûr d'avoir
compris
correctement) et on semble pouvoir les debugger par ftrace. Un peu
plus
d'explications là : https://medium.com/@boutnaru/the-linux-process-journey-kworker-f947634da73
Bon courage :-)
Et comment on fait pour savoir si ma carte est bien gérée ?
Les infos que j'ai trouvé la-dessus sont très vieille ...
Je suis sur un desktop, aucun suspend aucune hibernation.
J'étais passé à Wayland à une époque mais j'avais du revenir à X11 parce que ça se passait mal quand je lançais une appli depuis un
terminal loggué avec un autre user.
J'ai un peu peur de rechanger car de mémoire le retour à X11 n'avait
pas été super simple ...
Le 02/08/2023 à 13:10, Gaëtan Perrier a écrit :
Et comment on fait pour savoir si ma carte est bien gérée ?
Les infos que j'ai trouvé la-dessus sont très vieille ...
c'est vieux mais la page semble maintenue: https://nouveau.freedesktop.org/FeatureMatrix.html https://nouveau.freedesktop.org/CodeNames.html
Je suis sur un desktop, aucun suspend aucune hibernation.
OK
J'étais passé à Wayland à une époque mais j'avais du revenir à X11 parce que ça se passait mal quand je lançais une appli depuis un
terminal loggué avec un autre user.
J'ai un peu peur de rechanger car de mémoire le retour à X11
n'avait
pas été super simple ...
Ben en fait, je ne saisis pas, quand Gnome est installé sur Debian,
GDM
te permet de choisir entre quatre possibilités: Gnome/Wayland
(défaut),
Gnome/X11, Gnome-classic/Wayland, Gnome-classic/X11?
Donc naviguer entre les quatre possibilités nécessite juste de se déconnecter/reconnecter à la session en choisissant la bonne option?
Mise à part les freeze, as tu une bonne résolution sur l'écran,
et qu'elle est-elle ?
Il y a une commande qui créé le /etc/X11/xorg.conf,
je ne sais plus son nom, xorg-config... xorg.conf que l'on peut
compléter ensuite.
On peut aussi ajouter des configs dans /etc/default/grub
Un tutoriel :
https://wiki.archlinux.org/title/nouveau
Comme déjà dit, j'avais réussi à installer le pilote nouveau,
sans freeze, mais avec une résolution trop faible de 1024X768.
Si persistence du problème, acheter une nouvelle carte vidéo reconnue
?
Le mercredi 02 août 2023 à 13:35 +0200, didier gaumet a écrit :[...]
Ben en fait, je ne saisis pas, quand Gnome est installé sur Debian,
GDM
te permet de choisir entre quatre possibilités: Gnome/Wayland
(défaut),
Gnome/X11, Gnome-classic/Wayland, Gnome-classic/X11?
Donc naviguer entre les quatre possibilités nécessite juste de se
déconnecter/reconnecter à la session en choisissant la bonne option?
Chez moi j'ai juste GNOME, GNOME Classique et GNOME Flashback
(Metacity) ...
Le mercredi 02 août 2023 à 13:31 +0200, ajh-valmer a écrit :C'est déjà un très bon point, mais je ne m'explique pas les "freeze".
Mise à part les freeze, as tu une bonne résolution sur l'écran,
et qu'elle est-elle ?
Oui l'affichage est parfait, je suis en 1920x1200 :
Sans doute ? à essayer...Il y a une commande qui créé le /etc/X11/xorg.conf :X -configure ?
Le 03/08/2023 à 03:14, Gaëtan Perrier a écrit :
Le mercredi 02 août 2023 à 13:35 +0200, didier gaumet a écrit :[...]
Ben en fait, je ne saisis pas, quand Gnome est installé sur Debian,
GDM
te permet de choisir entre quatre possibilités: Gnome/Wayland
(défaut),
Gnome/X11, Gnome-classic/Wayland, Gnome-classic/X11?
Donc naviguer entre les quatre possibilités nécessite juste de se déconnecter/reconnecter à la session en choisissant la bonne option?
Chez moi j'ai juste GNOME, GNOME Classique et GNOME Flashback
(Metacity) ...
- ça doit dater d'un précédent ménage que tu as fait pour revenir à X11 au lieu de Wayland en pensant que c'était nécessaire. Mais ça me paraît une mauvaise idée: même gdm est une mini-session gnome-shell sous
Wayland, bien que dans ton cas il lance par la suite une session
ordinaire gnoem-shell sous X11.
Si tu veux revenir au standard debian, tu peux essayer de purger puis réinstaller gdm (vérifie que tu n'as pas crée un fichier /etc/apt/preferences dans lequel tu as placé des interdictions pour Wayland)
- pour tes freezes, bien que tu aies déjà supprimé ton xorg.conf, vérifies qu'il n'y a rien dans /etc/X11/xorg.conf.d/
vérifies aussi que tu n'as pas des options de lancement de ton noyau
(kms, résolution vidéo) dans grub
- sinon pour vérifier que ta carte peut fonctionner correctement avec un Debian standard et pilote Nouveau, fais tourner sur ton PC une clé USB Debian live (par défaut Gnome ce sera du Wayland et je ne crois pas que
tu puisses le changer, Plasma je ne sais pas ce que c'est par défaut,
les autres c'est du X11).
Si la clé USB Debian-live fonctionne correctement c'est ton installation qui est bancale ou Testing qui est bancal à l'instant t (mais je pense
qu de toutes façons tu te traînes quelques scories de manipulations un
peu hasardeuses dans ta config)
Le jeudi 03 août 2023 à 09:32 +0200, didier gaumet a écrit :
Le 03/08/2023 à 03:14, Gaëtan Perrier a écrit :
Le mercredi 02 août 2023 à 13:35 +0200, didier gaumet a écrit :[...]
Ben en fait, je ne saisis pas, quand Gnome est installé sur Debian, GDM
te permet de choisir entre quatre possibilités: Gnome/Wayland (défaut),
Gnome/X11, Gnome-classic/Wayland, Gnome-classic/X11?
Donc naviguer entre les quatre possibilités nécessite juste de se déconnecter/reconnecter à la session en choisissant la bonne option?
Chez moi j'ai juste GNOME, GNOME Classique et GNOME Flashback
(Metacity) ...
- ça doit dater d'un précédent ménage que tu as fait pour revenir à X11
au lieu de Wayland en pensant que c'était nécessaire. Mais ça me paraît
une mauvaise idée: même gdm est une mini-session gnome-shell sous Wayland, bien que dans ton cas il lance par la suite une session
ordinaire gnoem-shell sous X11.
Si tu veux revenir au standard debian, tu peux essayer de purger puis réinstaller gdm (vérifie que tu n'as pas crée un fichier /etc/apt/preferences dans lequel tu as placé des interdictions pour Wayland)
En fait c'est juste la ligne
 WaylandEnable=false
dans /etc/gdm3/daemon.conf qu'il faut commenter pour réactiver Wayland.
Par contre une fois sous Wayland vdpau_info n'est pas content ...
vdpauinfo
display: :0 screen: 0
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
Error creating VDPAU device: 1
alors que ça fonctionnait sous xorg ...
Gaëtan
Il y a une commande qui créé le /etc/X11/xorg.conf :X -configure ?
Par contre si j'ai bien compris faut la lancer sans que X soit démarré :Oui, mais est-ce important ? Faire les 2 alors.
On Friday 04 August 2023 02:05:09 Gaëtan Perrier wrote:
ÂIl y a une commande qui créé le /etc/X11/xorg.conf :X -configure ?
Par contre si j'ai bien compris faut la lancer sans que X soit démarré :Oui, mais est-ce important ? Faire les 2 alors.
As tu bien un fichier xorg.conf ?
(le montrer)
Le 04/08/2023 à 02:06, Gaëtan Perrier a écrit :
Par contre une fois sous Wayland vdpau_info n'est pas content ...
vdpauinfo
display: :0Â Â screen: 0
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
Error creating VDPAU device: 1
alors que ça fonctionnait sous xorg ...
Gaëtan
je peux me tromper mais je pense que ta désinstallation des pilotes
nvidia n'a pas été complète (pour ça si je comprends bien (je n'ai jamais eu de nvidia), il aurait fallu employer la procédure de désinstallation complète nvidia).
En tout cas ça me semble bizarre que ce soit l'absence du backend libvdpau_nvidia.so dont se plaigne vdpauinfo vu que c'est le backend
pour le pilote proprio, pas pour Nouveau.
Pour Nouveau:
- VAAPI: vérifier que mesa-va-drivers est installé ou l'installer
- VDPAU: vérifier que vdpau-driver-all est installé ou l'installer
cf:
le wiki Debian
https://wiki.debian.org/HardwareVideoAcceleration
et, plus détaillé, le wiki Archlinux, qui te détaillera aussi les
couches des traductions entre VAAPI te CDPAU dans un sens et dans
l'autre, parfois utile pour bénéficier d'une accélération sur des matériels qui ne supportent que certains machins particuliers: https://wiki.archlinux.org/title/Hardware_video_acceleration
(normalement la série Geforce 500 est directement compatible VAAPI et
VDPAU sans souci)
Sinon j'ai le même problème de crash de nouveau avec wayland qu'avec xorg. Sauf
qu'avec xorg j'arrive à redémarrer la machine mais pas avec wayland.
- essayer de faire un apt purge *nvidia* pour virer les restes de
fichiers de conf' qui doivent encore traîner
~]# apt purge *nvidia*
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait    Â
E: Impossible de trouver le paquet glxinfo_nvidia.txt
LÃ je ne sais pas quoi penser vu qu'il n'existe pas de paquet avec un tel nom
...
je ne sais pas trop quoi te conseiller, Ã part
- tester une livekey Debian 12 pour voir si tu as des freezes, pour éliminer la possibilité que l'association de ton matériel et sa gestion par Nouveau génère les crashes. Si ça crashe c'est vraisemblablement que tu ne peux obtenir un bon fonctionnement que par le pilote proprio. Sinon c'est que ton installation Testing est bancale
- vérifier (apt policy) entre autres les versions de libc6 et libdrm* installées sont les dernières disponibles
- chercher les paquets obsolètes (aptitude search '~o')
- essayer de faire un apt purge *nvidia* pour virer les restes de
fichiers de conf' qui doivent encore traîner
- si pas plus de succès, envisager une réinstallation propre de Debian (après sauvegarde de tes données), parce que honnêtement, si j'ai bien compris, tu fais des mises-à -jour depuis 20 ans, ça m'étonnerait que ton système ne soit pas bancal ;-)
Le dimanche 06 août 2023 à 16:19 +0200, Gaëtan Perrier a écrit :[...]
[...]~]# apt purge *nvidia*
En fait il faut faire apt purge "*nvidia*" sinon il prend les fichier contenant
nvidia qui sont dans le répertoire ...
Les paquets suivants seront ENLEVÉS :
firmware-nvidia-gsp* glx-diversions* libnvidia-allocator1*
libnvidia-egl-gbm1* libnvidia-egl-wayland1* nvidia-installer-cleanup*
Y a pas grand chose qui traînait.
refais un vainfo et un vdpauinfo, tu devrais avoir de meilleursrésultats qu'auparavant
et surtout, si il était auparavant absent et que tu as installé lepaquet firmware-misc-nonfree, ça devrait au moins en partie pouvoir
Le samedi 05 août 2023 à 11:19 +0200, didier gaumet a écrit :[...]
- chercher les paquets obsolètes (aptitude search '~o')
rien concernant le système graphique.
Sinon en faisant un update-initramfs (pour une autre raison) j'ai ces messages[...]
qui sont sortis:
update-initramfs -k all -u
update-initramfs: Generating /boot/initrd.img-6.4.0-1-amd64
W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_ahesasc.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/desc.bin for module nouveau
Le 06/08/2023 à 16:38, Gaëtan Perrier a écrit :
Le dimanche 06 août 2023 à 16:19 +0200, Gaëtan Perrier a écrit :[...]
[...]~]# apt purge *nvidia*
En fait il faut faire apt purge "*nvidia*" sinon il prend les fichier contenant
nvidia qui sont dans le répertoire ...
Les paquets suivants seront ENLEVÉS :
  firmware-nvidia-gsp* glx-diversions* libnvidia-allocator1*
  libnvidia-egl-gbm1* libnvidia-egl-wayland1* nvidia-installer-cleanup*
Y a pas grand chose qui traînait.
c'est pas tellement qu'il reste des bibliothèques proprio nvidia qui
était gênant, c'est le fait que les scripts d'installation de ces procédures avaient probablement paramétré que ta caret devait être gérée
à tous les niveaux par le pilote proprio, donc Nouveau ne pouvait fonctionner correctement.
Si tu as de la chance et que tout s'est bien passé la purge a non
seulement supprimé les paquets mais aussi supprimé certains fichiers de conf et changé des valeurs de paramètres dans les fichiers de conf restant.
refais un vainfo et un vdpauinfo, tu devrais avoir de meilleursrésultats qu'auparavant
et surtout, si il était auparavant absent et que tu as installé lepaquet firmware-misc-nonfree, ça devrait au moins en partie pouvoir expliquer tes problèmes et les résoudre.
Le 6 août 2023 Gaëtan Perrier a écrit :
tout ces firmwares semblent faire partie du paquet firmware-misc-non-free qui ne doit pas être installé chez toi, donc installe-le
Il est installé mais ils ne sont pas dedans.
update-initramfs liste tous les firmwares qui peuvent être demandés par le kernel. Mais tu as juste besoin de ceux qui vont bien pour ton
matériel. Donc tu peux ignorer ces warnings si ton matériel est bien pris en charge par un firmware présent.
Ou tu peux aller piocher sur internet
des firmwares en plus, mais là il faut chercher spécifiquement ce qui te manque. Par exemple moi je vais piocher sur : https://anduin.linuxfromscratch.org/sources/linux-firmware/ https://github.com/intel/backport-iwlwifi https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files.git
Les pilotes nvidia legacy 390 de sid étant maintenant compatibles avec les kernel jusqu'à 6.5 je suis repassé sur le pilote proprio.
Avec nouveau c'était invivable.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 166:44:30 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,529 |