Re: [Sid] Nouveau: only one monitor after 6.6.15 to 6.7.9 upgrade
On 2024-04-03 21:39 +0200, Greg wrote: > I have two HP Z30i connected to Nvidia GeForce GTX 670. After last > upgrade I'm able to use only one monitor. > > When running linux-image-6.7.9: > > # dmesg | grep nouveau | cut -b 16- > nouveau :01:00.0: vgaarb: deactivate vga console > nouveau :01:00.0: NVIDIA GK104 (0e4090a2) > nouveau :01:00.0: bios: version 80.04.19.00.0f > nouveau :01:00.0: fb: 2048 MiB GDDR5 > nouveau 0000:01:00.0: DRM: VRAM: 2048 MiB > nouveau 0000:01:00.0: DRM: GART: 1048576 MiB > nouveau :01:00.0: DRM: TMDS table version 2.0 > nouveau :01:00.0: DRM: MM: using COPY for buffer copies > snd_hda_intel :01:00.1: bound :01:00.0 (ops > nv50_audio_component_bind_ops [nouveau]) > [drm] Initialized nouveau 1.4.0 20120801 for :01:00.0 on minor 0 > fbcon: nouveaudrmfb (fb0) is primary device > nouveau :01:00.0: vgaarb: VGA decodes changed: > olddecodes=io+mem,decodes=io+mem:owns=io+mem > nouveau :01:00.0: [drm] fb0: nouveaudrmfb frame buffer device > # xrandr > Screen 0: minimum 320 x 200, current 2560 x 1600, maximum 16384 x 16384 > DVI-I-1 connected 2560x1600+0+0 (normal left inverted right x axis y > axis) 641mm x 400mm >2560x1600 59.97*+ >1920x1200 59.95 >1920x1080 60.00 >1600x1200 60.00 >1680x1050 59.88 >1280x1024 60.02 >1440x900 59.90 >1280x800 59.91 >1280x720 60.00 >1024x768 60.00 >800x600 60.32 >640x480 59.94 >720x400 70.08 > DVI-D-1 disconnected (normal left inverted right x axis y axis) > HDMI-1 disconnected (normal left inverted right x axis y axis) > DP-1 disconnected (normal left inverted right x axis y axis) > > When running linux-image-6.6.15: > > # dmesg | grep nouveau | cut -b 16- > nouveau :01:00.0: vgaarb: deactivate vga console > nouveau 0000:01:00.0: NVIDIA GK104 (0e4090a2) > nouveau :01:00.0: bios: version 80.04.19.00.0f > nouveau :01:00.0: fb: 2048 MiB GDDR5 > nouveau :01:00.0: DRM: VRAM: 2048 MiB > nouveau :01:00.0: DRM: GART: 1048576 MiB > nouveau :01:00.0: DRM: TMDS table version 2.0 > nouveau :01:00.0: DRM: DCB version 4.0 > nouveau :01:00.0: DRM: DCB outp 00: 01000f02 00020030 > nouveau :01:00.0: DRM: DCB outp 01: 02000f00 > nouveau :01:00.0: DRM: DCB outp 02: 08011f82 00020030 > nouveau 0000:01:00.0: DRM: DCB outp 03: 02022f62 00020010 > nouveau :01:00.0: DRM: DCB outp 04: 04833fb6 0f420010 > nouveau :01:00.0: DRM: DCB outp 05: 04033f72 00020010 > nouveau :01:00.0: DRM: DCB conn 00: 1030 > nouveau :01:00.0: DRM: DCB conn 01: 00020131 > nouveau :01:00.0: DRM: DCB conn 02: 00010261 > nouveau 0000:01:00.0: DRM: DCB conn 03: 2346 > nouveau :01:00.0: DRM: MM: using COPY for buffer copies > snd_hda_intel :01:00.1: bound :01:00.0 (ops > nv50_audio_component_bind_ops [nouveau]) > [drm] Initialized nouveau 1.4.0 20120801 for :01:00.0 on minor 0 > nouveau :01:00.0: vgaarb: VGA decodes changed: > olddecodes=io+mem,decodes=io+mem:owns=io+mem > fbcon: nouveaudrmfb (fb0) is primary device > nouveau :01:00.0: [drm] fb0: nouveaudrmfb frame buffer device > # xrandr > Screen 0: minimum 320 x 200, current 5120 x 1600, maximum 16384 x 16384 > DVI-I-1 connected 2560x1600+2560+0 (normal left inverted right x axis > y axis) 641mm x 400mm >2560x1600 59.97*+ >1920x1200 59.95 >1920x1080 60.00 >1600x1200 60.00 >1680x1050 59.88 >1280x1024 60.02 >1440x900 59.90 >1280x800 59.91 >1280x720 60.00 >1024x768 60.00 >800x600 60.32 >640x480 59.94 >720x400 70.08 > DVI-D-1 connected 2560x1600+0+0 (normal left inverted right x axis y > axis) 641mm x 400mm >2560x1600 59.97*+ >1920x1200 59.95 >1920x1080 60.00 >1600x1200 60.00 >1680x1050 59.88 >1280x1024 60.02 >1440x900 59.90 >1280x800 59.91 >1280x720 60.00 >1024x768 60.00 >800x600 60.32 >640x480 59.94 >720x400 70.08 > HDMI-1 disconnected (normal left inverted right x axis y axis) > DP-1 disconnected (normal left inverted right x axis y axis) > > Any suggestions? File a bug against the kernel: reboot to the 6.7 kernel if it is not currently running, install the reportbug package if it is not installed already, then run $ reportbug linux-image-$(uname -r) Good luck, Sven
[Sid] Nouveau: only one monitor after 6.6.15 to 6.7.9 upgrade
Hi there, I have two HP Z30i connected to Nvidia GeForce GTX 670. After last upgrade I'm able to use only one monitor. When running linux-image-6.7.9: # dmesg | grep nouveau | cut -b 16- nouveau :01:00.0: vgaarb: deactivate vga console nouveau :01:00.0: NVIDIA GK104 (0e4090a2) nouveau :01:00.0: bios: version 80.04.19.00.0f nouveau :01:00.0: fb: 2048 MiB GDDR5 nouveau :01:00.0: DRM: VRAM: 2048 MiB nouveau :01:00.0: DRM: GART: 1048576 MiB nouveau :01:00.0: DRM: TMDS table version 2.0 nouveau :01:00.0: DRM: MM: using COPY for buffer copies snd_hda_intel :01:00.1: bound :01:00.0 (ops nv50_audio_component_bind_ops [nouveau]) [drm] Initialized nouveau 1.4.0 20120801 for :01:00.0 on minor 0 fbcon: nouveaudrmfb (fb0) is primary device nouveau :01:00.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=io+mem nouveau :01:00.0: [drm] fb0: nouveaudrmfb frame buffer device # xrandr Screen 0: minimum 320 x 200, current 2560 x 1600, maximum 16384 x 16384 DVI-I-1 connected 2560x1600+0+0 (normal left inverted right x axis y axis) 641mm x 400mm 2560x1600 59.97*+ 1920x1200 59.95 1920x1080 60.00 1600x1200 60.00 1680x1050 59.88 1280x1024 60.02 1440x900 59.90 1280x800 59.91 1280x720 60.00 1024x768 60.00 800x600 60.32 640x480 59.94 720x400 70.08 DVI-D-1 disconnected (normal left inverted right x axis y axis) HDMI-1 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) When running linux-image-6.6.15: # dmesg | grep nouveau | cut -b 16- nouveau :01:00.0: vgaarb: deactivate vga console nouveau :01:00.0: NVIDIA GK104 (0e4090a2) nouveau :01:00.0: bios: version 80.04.19.00.0f nouveau :01:00.0: fb: 2048 MiB GDDR5 nouveau :01:00.0: DRM: VRAM: 2048 MiB nouveau :01:00.0: DRM: GART: 1048576 MiB nouveau :01:00.0: DRM: TMDS table version 2.0 nouveau :01:00.0: DRM: DCB version 4.0 nouveau :01:00.0: DRM: DCB outp 00: 01000f02 00020030 nouveau :01:00.0: DRM: DCB outp 01: 02000f00 nouveau :01:00.0: DRM: DCB outp 02: 08011f82 00020030 nouveau :01:00.0: DRM: DCB outp 03: 02022f62 00020010 nouveau :01:00.0: DRM: DCB outp 04: 04833fb6 0f420010 nouveau :01:00.0: DRM: DCB outp 05: 04033f72 00020010 nouveau :01:00.0: DRM: DCB conn 00: 1030 nouveau :01:00.0: DRM: DCB conn 01: 00020131 nouveau :01:00.0: DRM: DCB conn 02: 00010261 nouveau :01:00.0: DRM: DCB conn 03: 2346 nouveau :01:00.0: DRM: MM: using COPY for buffer copies snd_hda_intel :01:00.1: bound :01:00.0 (ops nv50_audio_component_bind_ops [nouveau]) [drm] Initialized nouveau 1.4.0 20120801 for :01:00.0 on minor 0 nouveau :01:00.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=io+mem fbcon: nouveaudrmfb (fb0) is primary device nouveau :01:00.0: [drm] fb0: nouveaudrmfb frame buffer device # xrandr Screen 0: minimum 320 x 200, current 5120 x 1600, maximum 16384 x 16384 DVI-I-1 connected 2560x1600+2560+0 (normal left inverted right x axis y axis) 641mm x 400mm 2560x1600 59.97*+ 1920x1200 59.95 1920x1080 60.00 1600x1200 60.00 1680x1050 59.88 1280x1024 60.02 1440x900 59.90 1280x800 59.91 1280x720 60.00 1024x768 60.00 800x600 60.32 640x480 59.94 720x400 70.08 DVI-D-1 connected 2560x1600+0+0 (normal left inverted right x axis y axis) 641mm x 400mm 2560x1600 59.97*+ 1920x1200 59.95 1920x1080 60.00 1600x1200 60.00 1680x1050 59.88 1280x1024 60.02 1440x900 59.90 1280x800 59.91 1280x720 60.00 1024x768 60.00 800x600 60.32 640x480 59.94 720x400 70.08 HDMI-1 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) Any suggestions? Greg
CNRS: nouveau système de gestion des missions, on n'en peut plus!
Bonjour, Je viens de signer la pétition "CNRS: nouveau système de gestion des missions, on n'en peut plus!" et je souhaitais savoir si vous voudriez nous aider en ajoutant votre signature. Notre objectif est d'atteindre 2 500 signatures et nous avons besoin de plus de soutiens. Pour en savoir plus et pour signer, c'est ici: https://chng.it/swYTsqL5DH Merci ! Par ailleurs, je cherche des contributeurs et des utilisateurs au logiciel libre moteur d'inférence RefPerSys en http://refpersys.org/ et code en https://github.com/RefPerSys/RefPerSys/ Librement -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Custom kernel 6.1.55 almost unusable cause nouveau
Hi, I compile the kernel for many years, I optimize the kernel compile process using the bdver1 gcc optimization option applying a patch to "arch/x86/Makefile" in the Linux source tree path. Sadly with the 6.1.55 things went wrong it freeze many time, the 6.1.52 is much more stable with nouveau driver, I don't know why. I attach two files, the kernel log and the .config used for compile the 6.1.55 kernel version. The log file is very large, I suggest to filter it with "grep -v" command in order to avoid duplicate entries. I notice that in the kernel configuration program (make menuconfig) for nouveau driver there are four debug options: CONFIG_NOUVEAU_DEBUG, CONFIG_NOUVEAU_DEBUG_DEFAULT, CONFIG_NOUVEAU_DEBUG_MMU and CONFIG_NOUVEAU_DEBUG_PUSH. If you want I can set/enable those options to have more debug information. Does anybody have any clue to make 6.1.55 reliable on my system? Thank you in advance! -- Franco Martelli config-6.1.55.xz Description: application/xz kernel-nouveau.log.xz Description: application/xz
Re: [testing] passage du pilote proprio à nouveau
Gaëtan Perrier a écrit : > Par exemple le raytracing ne semble pas supporté sur les cartes AMD > alors qu'il fonctionne sur Nvidia (ainsi que le DLSS) ? Chez AMD, on trouve le FSR qui semble aussi efficace. Quant au raytracing, la carte que j'utilise ne doit pas savoir qu'il n'est pas supporté. JKB
Re: [testing] passage du pilote proprio à nouveau
Le mercredi 13 septembre 2023 à 15:50 +0200, BERTRAND Joël a écrit : > Gaëtan Perrier a écrit : > > Je suis d'accord sur le fond mais le problème c'est que les cartes > > NVIDIA, d'après tout ce je lis, semblent être les plus performantes. > > Là j'envisage de changer de PC car il commence à atteindre ses limites, > > et en cherchant un peu je vois que le support des nouvelles cartes Intel > > ARC semble être foireux, que le support des AMD semble bon et libre mais > > que côté perf ce n'est pas encore ça et au final NVIDIA et devant tout > > le monde mais avec des pilotes proprio. :( > > Franchement, j'aimerais bien savoir ce qu'on reproche aux cartes > AMD. > J'ai un truc comme ça pour faire de la CAO (bi écran) sur un i9, ça > tient vraiment bien la route, même pour des jeux en 3D : > Par exemple le raytracing ne semble pas supporté sur les cartes AMD alors qu'il fonctionne sur Nvidia (ainsi que le DLSS) ? Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote nouveau à proprio
Même pour des matériels disposant d'un bon pilote totalement libre le support disparaît... Ma carte a plus de 10 ans et fonctionne encore avec les pilotes proprios. Le 13 septembre 2023 20:52:45 GMT+02:00, "BERTRAND Joël" a écrit : >ajh-valmer a écrit : >> Les cartes Nvidia ont une très bonne qualité de rendu à l'écran. >> avec leur pilote, il y a une configuration sophistiquée de la carte, >> permettant d'améliorer le rendu (nvidia-settings). >> Les pilotes libres n'ont pas cet outil de config. >> Seulement, leurs pilotes ne suivent pas toujours les distributions >> et les versions. > > Je leur reproche surtout le fait qu'après quelques années de ne plus >être supportées. J'ai des lots de telles cartes et ça m'a toujours dérangé. > > Il n'y a aucune raison /valable/ à cela. > -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: [testing] passage du pilote nouveau à proprio
ajh-valmer a écrit : > Les cartes Nvidia ont une très bonne qualité de rendu à l'écran. > avec leur pilote, il y a une configuration sophistiquée de la carte, > permettant d'améliorer le rendu (nvidia-settings). > Les pilotes libres n'ont pas cet outil de config. > Seulement, leurs pilotes ne suivent pas toujours les distributions > et les versions. Je leur reproche surtout le fait qu'après quelques années de ne plus être supportées. J'ai des lots de telles cartes et ça m'a toujours dérangé. Il n'y a aucune raison /valable/ à cela.
Re: [testing] passage du pilote nouveau à proprio
On Wednesday 13 September 2023 13:41:45 BERTRAND Joël wrote: > > On Tuesday 12 September 2023 23:24:24 Gaëtan Perrier wrote: > >> 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. > ajh-valmer a écrit : > > Je n'ai jamais réussi à faire fonctionner correctement un > > pilote "nouveau". > > Ce sont les pilotes proprio qui fonctionnent vraiment. > > Ce sont les "terroristes libristes" qui imposent d'utiliser que du Libre > > à 100% mais parfois ce n'est pas possible. On Wednesday 13 September 2023 13:41:45 BERTRAND Joël wrote: >Sans être terroriste libriste, nvidia est un machin qui pose problème > parce qu'au bout d'un certain temps, on se retrouve à devoir utiliser le > pilote libre faute de support. Je boycotte scrupuleusement toutes les > cartes nvidia pour cette raison. Je changerai d'avis sur nvidia le jour > où nvidia daignera fournir les specs de ses cartes. Les cartes Nvidia ont une très bonne qualité de rendu à l'écran. avec leur pilote, il y a une configuration sophistiquée de la carte, permettant d'améliorer le rendu (nvidia-settings). Les pilotes libres n'ont pas cet outil de config. Seulement, leurs pilotes ne suivent pas toujours les distributions et les versions.
Re: X: how to *really* switch from nouveau to modesetting?
Felix Miata wrote on 9/12/23 11:51: You really should eliminate that xorg.conf file, and if the problem continues, don't assume it's the kernel driver at fault. Just report a bug if so inclined. Where would depend on behavior after removing xorg.conf. If it fixes the problem, there is almost assuredly no bug anywhere at all affecting you. If with modesetting it's gone, but with xserver-xorg-video-nouveau installed and in use it remains, then it would be good to report a nouveau DDX bug, though the problem could be DRI or Mesa. Unreported bugs can go a very long time before a fix occurs, if ever. What you are now experiencing is not acceptable behavior. 13 years of age is too young to accept FOSS performance degradation or need GPU upgrade. I have removed /etc/X11/xorg.conf, and the problem remains. So in this case, where should I report the issue? Doc -- Web: http://enginehousebooks.com/drevans
Re: [testing] passage du pilote proprio à nouveau
Gaëtan Perrier a écrit : > Je suis d'accord sur le fond mais le problème c'est que les cartes > NVIDIA, d'après tout ce je lis, semblent être les plus performantes. > Là j'envisage de changer de PC car il commence à atteindre ses limites, > et en cherchant un peu je vois que le support des nouvelles cartes Intel > ARC semble être foireux, que le support des AMD semble bon et libre mais > que côté perf ce n'est pas encore ça et au final NVIDIA et devant tout > le monde mais avec des pilotes proprio. :( Franchement, j'aimerais bien savoir ce qu'on reproche aux cartes AMD. J'ai un truc comme ça pour faire de la CAO (bi écran) sur un i9, ça tient vraiment bien la route, même pour des jeux en 3D : 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] Flags: bus master, fast devsel, latency 0, IRQ 132 Memory at 42 (64-bit, prefetchable) [size=8G] Memory at 41 (64-bit, prefetchable) [size=2M] I/O ports at 4000 [size=256] Memory at a020 (32-bit, non-prefetchable) [size=256K] Expansion ROM at 000c [disabled] [size=128K] Capabilities: [48] Vendor Specific Information: Len=08 Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150] Advanced Error Reporting Capabilities: [200] Physical Resizable BAR Capabilities: [270] Secondary PCI Express Capabilities: [2b0] Address Translation Service (ATS) Capabilities: [2c0] Page Request Interface (PRI) Capabilities: [2d0] Process Address Space ID (PASID) Capabilities: [320] Latency Tolerance Reporting Capabilities: [328] Alternative Routing-ID Interpretation (ARI) Capabilities: [370] L1 PM Substates Kernel driver in use: amdgpu Kernel modules: amdgpu
Re: [testing] passage du pilote proprio à nouveau
Je suis d'accord sur le fond mais le problème c'est que les cartes NVIDIA, d'après tout ce je lis, semblent être les plus performantes. Là j'envisage de changer de PC car il commence à atteindre ses limites, et en cherchant un peu je vois que le support des nouvelles cartes Intel ARC semble être foireux, que le support des AMD semble bon et libre mais que côté perf ce n'est pas encore ça et au final NVIDIA et devant tout le monde mais avec des pilotes proprio. :( Gaëtan Le 13 septembre 2023 13:41:45 GMT+02:00, "BERTRAND Joël" a écrit : >ajh-valmer a écrit : >> On Tuesday 12 September 2023 23:24:24 Gaëtan Perrier wrote: >>> 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. >> >> Je n'ai jamais réussi à faire fonctionner correctement un pilote "nouveau". >> Ce sont les pilotes proprio qui fonctionnent vraiment. >> >> Ce sont les "terroristes libristes" qui imposent d'utiliser que du Libre à >> 100% mais parfois ce n'est pas possible. > > Sans être terroriste libriste, nvidia est un machin qui pose problème >parce qu'au bout d'un certain temps, on se retrouve à devoir utiliser le >pilote libre faute de support. Je boycotte scrupuleusement toutes les >cartes nvidia pour cette raison. Je changerai d'avis sur nvidia le jour >où nvidia daignera fournir les specs de ses cartes. > > JKB > -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: [testing] passage du pilote proprio à nouveau
ajh-valmer a écrit : > On Tuesday 12 September 2023 23:24:24 Gaëtan Perrier wrote: >> 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. > > Je n'ai jamais réussi à faire fonctionner correctement un pilote "nouveau". > Ce sont les pilotes proprio qui fonctionnent vraiment. > > Ce sont les "terroristes libristes" qui imposent d'utiliser que du Libre à > 100% mais parfois ce n'est pas possible. Sans être terroriste libriste, nvidia est un machin qui pose problème parce qu'au bout d'un certain temps, on se retrouve à devoir utiliser le pilote libre faute de support. Je boycotte scrupuleusement toutes les cartes nvidia pour cette raison. Je changerai d'avis sur nvidia le jour où nvidia daignera fournir les specs de ses cartes. JKB
Re: [testing] passage du pilote proprio à nouveau
On Tuesday 12 September 2023 23:24:24 Gaëtan Perrier wrote: > 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. Je n'ai jamais réussi à faire fonctionner correctement un pilote "nouveau". Ce sont les pilotes proprio qui fonctionnent vraiment. Ce sont les "terroristes libristes" qui imposent d'utiliser que du Libre à 100% mais parfois ce n'est pas possible.
Re: [testing] passage du pilote proprio à nouveau
Salut, 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. A+ Gaëtan signature.asc Description: This is a digitally signed message part
Re: X: how to *really* switch from nouveau to modesetting?
D. R. Evans composed on 2023-09-12 11:12 (UTC-0600): > Felix Miata wrote: > From the rest of your post, it sounds like everything is as it should be, > except that I should probably remove the /etc/X11/xorg.conf file. And I could > also re-install the xserver-xorg-video-nouveau without effecting any change; > but for now I think I'll just keep things as they are and just note these as > possible changes to try sometime, with the expectation that they won't make > any practical difference, but might make the system a bit cleaner to > administer. You really should eliminate that xorg.conf file, and if the problem continues, don't assume it's the kernel driver at fault. Just report a bug if so inclined. Where would depend on behavior after removing xorg.conf. If it fixes the problem, there is almost assuredly no bug anywhere at all affecting you. If with modesetting it's gone, but with xserver-xorg-video-nouveau installed and in use it remains, then it would be good to report a nouveau DDX bug, though the problem could be DRI or Mesa. Unreported bugs can go a very long time before a fix occurs, if ever. What you are now experiencing is not acceptable behavior. 13 years of age is too young to accept FOSS performance degradation or need GPU upgrade. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: X: how to *really* switch from nouveau to modesetting?
Felix Miata wrote on 9/11/23 19:57: You did it. You made the switch. But see below. (There are multiple components to GPU support in Linux.) (There is no "the" nouveau "driver". Graphics support is in the hands of multiple software components, several of which incorporate the string "nouveau" in naming.) I'm glad that you understand this stuff. It certainly seems non-obvious. And the days of good O'Reilly books that walk one through details like this seem to be long gone :-( From the rest of your post, it sounds like everything is as it should be, except that I should probably remove the /etc/X11/xorg.conf file. And I could also re-install the xserver-xorg-video-nouveau without effecting any change; but for now I think I'll just keep things as they are and just note these as possible changes to try sometime, with the expectation that they won't make any practical difference, but might make the system a bit cleaner to administer. And, from what you say here: > D. R. Evans composed on 2023-09-11 11:47 (UTC-0600): > >> Graphics: >> Device-1: NVIDIA GF108 [GeForce GT 430] vendor: Gigabyte driver: nouveau > > Above shows your kernel DEVICE driver is nouveau. It ships specifically for each > kernel with each kernel. For NVidia GPUs there is no other FOSS device driver > option for normal use with KMS enabled, which maximum possible FOSS performance > unconditionally requires. With KMS disabled, there is a crude generic option with > limited resolutions available that no one ever would use purposely unless too > naive to understand the opportunity loss. It's for fallback and troubleshooting > when normal is unavailable. it sounds like the issue must be in the nouveau kernel device driver, and there's nothing I can really do to change that. So I guess I will just wait and hope that some future update removes the problem. ⁂ Just for the record, to provide some context for anyone finding this thread as a result of a search: 1. The issue is that black-on-white text has a "tail" extending some distance on the right of the text (I don't know how to describe it any better than that). 2. It began with a normal bullseye update. Before that, there was no problem at all. 3. Every update and upgrade since then has exhibited the problem. 4. The monitor is KVM-switchable to another bookworm installation, which does not (and never has) exhibited the problem. Doc -- Web: http://enginehousebooks.com/drevans
Re: X: how to *really* switch from nouveau to modesetting?
You did it. You made the switch. But see below. (There are multiple components to GPU support in Linux.) (There is no "the" nouveau "driver". Graphics support is in the hands of multiple software components, several of which incorporate the string "nouveau" in naming.) D. R. Evans composed on 2023-09-11 11:47 (UTC-0600): > Graphics: >Device-1: NVIDIA GF108 [GeForce GT 430] vendor: Gigabyte driver: nouveau Above shows your kernel DEVICE driver is nouveau. It ships specifically for each kernel with each kernel. For NVidia GPUs there is no other FOSS device driver option for normal use with KMS enabled, which maximum possible FOSS performance unconditionally requires. With KMS disabled, there is a crude generic option with limited resolutions available that no one ever would use purposely unless too naive to understand the opportunity loss. It's for fallback and troubleshooting when normal is unavailable. > v: kernel non-free: series: 390.xx+ status: legacy-active (EOL~late 2022) > arch: Fermi code: GF1xx process: 40/28nm built: 2010-16 pcie: gen: 1 > speed: 2.5 GT/s lanes: 16 ports: active: HDMI-A-1 empty: DVI-I-1,VGA-1 > bus-ID: 04:00.0 chip-ID: 10de:0de1 class-ID: 0300 >Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 driver: X: > loaded: modesetting dri: nouveau gpu: nouveau display-ID: :0 screens: 1 Above shows your loaded X DISPLAY driver is modesetting, the one & only competent FOSS alternative to the nouveau that ships in xserver-xorg-video-nouveau. The DRI driver is another nouveau, another piece of the graphics support puzzle, another only option for competent FOSS NVidia GPU support. # dpkg-query -W | grep nouveau libdrm-nouveau2:amd64 2.4.114-1+b1amd64 Userspace interface to nouveau-specific kernel DRM services -- runtime # https://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure > My xorg.conf file currently looks like this: You should have no /etc/X11/xorg.conf file. Proprietary NVidia drivers and configurators normally make one. It's just something they do. For FOSS drivers, /etc/X11/xorg.conf is an anachronism that remains occasionally useful. Any such file created by NVidia installation or reconfiguration must be removed, or severely edited, in order to revert from proprietary NVidia driver use to FOSS-only use. > And the file that Felix suggested I install, > /etc/X11/xorg.conf.d/50-device.conf, looks like this: > Section "Device" >Identifier "DDX" > Driver "modesetting" > # Driver "nouveau" > EndSection That's a valid available option for overriding the selection Xorg would make on its automagic own. Its existence overrides any conflicting equivalent in any existing /etc/X11/xorg.conf. By having it it is normally not necessary to keep xserver-xorg-video-nouveau uninstalled to keep X keeping the modesetting DIX loaded instead of the nouveau DDX. DIX: Device Independent X display driver (works with most GPUs regarless of brand) DDX: Device Dependent X display driver (specific to one brand of GPU) -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
X: how to *really* switch from nouveau to modesetting?
This is a follow-on to the thread that started with: https://lists.debian.org/debian-user/2023/05/msg00657.html Following the upgrade to bookworm that I recently performed, I was hoping that the problem described in the first post in that thread would magically go away. It didn't :-( Felix suggested removing the nouveau driver and using "modesetting" as the driver. I have removed the nouveau driver -- or at least I thought I did -- by executing: apt-get remove xserver-xorg-video-nouveau which moved the packages: xserver-xorg-video-nouveau xserver-xorg-video-all Upon rebooting into bookworm, though, I still see the original problem, as described in the original post. If I look to see what driver is being used: [ZB:~] inxi -SGaz System: Kernel: 6.1.0-12-amd64 arch: x86_64 bits: 64 compiler: gcc v: 12.2.0 parameters: BOOT_IMAGE=/BOOT/debian@/vmlinuz-6.1.0-12-amd64 root=ZFS=/ROOT/debian ro root=ZFS=rpool/ROOT/debian Desktop: Trinity info: kicker wm: Twin vt: 7 dm: LightDM v: 1.26.0 Distro: Debian GNU/Linux 12 (bookworm) Graphics: Device-1: NVIDIA GF108 [GeForce GT 430] vendor: Gigabyte driver: nouveau v: kernel non-free: series: 390.xx+ status: legacy-active (EOL~late 2022) arch: Fermi code: GF1xx process: 40/28nm built: 2010-16 pcie: gen: 1 speed: 2.5 GT/s lanes: 16 ports: active: HDMI-A-1 empty: DVI-I-1,VGA-1 bus-ID: 04:00.0 chip-ID: 10de:0de1 class-ID: 0300 Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 driver: X: loaded: modesetting dri: nouveau gpu: nouveau display-ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x317mm (20.00x12.48") s-diag: 599mm (23.57") Monitor-1: HDMI-A-1 mapped: HDMI-1 model: VGA TO HDMI built: 2013 res: 1920x1080 hz: 60 dpi: 96 gamma: 1.2 size: 509x286mm (20.04x11.26") diag: 584mm (23") ratio: 16:9 modes: max: 1920x1080 min: 640x480 API: OpenGL v: 4.3 Mesa 22.3.6 renderer: NVC1 direct-render: Yes [ZB:~] So the nouveau driver still seems to be available and in use, despite being removed. My xorg.conf file currently looks like this: [ZB:~] cat /etc/X11/xorg.conf Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 Screen 1 "Screen1" RightOf "Screen0" InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "CoreKeyboard" EndSection Section "Files" ModulePath "/usr/lib/xorg/modules" FontPath "/usr/share/fonts/X11/misc" FontPath "/usr/share/fonts/X11/cyrillic" FontPath "/usr/share/fonts/X11/100dpi/:unscaled" FontPath "/usr/share/fonts/X11/75dpi/:unscaled" FontPath "/usr/share/fonts/X11/Type1" FontPath "/usr/share/fonts/X11/100dpi" FontPath "/usr/share/fonts/X11/75dpi" FontPath "built-ins" EndSection Section "Module" Load "glx" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/input/mice" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName"Monitor Model" EndSection Section "Monitor" Identifier "Monitor1" VendorName "Monitor Vendor" ModelName"Monitor Model" EndSection [54/136] Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz", ### : "%" ### [arg]: arg optional #Option "SWcursor" # [] #Option "HWcursor" # [] #Option "NoAccel" # [] #Option "ShadowFB" # [] #Option "VideoKey" # #Option "WrappedFB" # [] #Option "GLXVBlank" # [] #Option "ZaphodHeads" # #Option "PageFlip" # [] #Option "SwapLimit" # #Option "AsyncUTSDFS" # [] #Option "
Re: Nvidia 390 driver no longer available for Bookworm; nouveau constantly freezes. Solutions?
On 17.08.2023 20:48, Luiz Romário Santana Rios wrote: Hello, all, (Please cc me when replying, I'm not subscribed to the mailing list) I have (according do lspci) a NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) graphics card. The correct proprietary driver for this card seems to be the Nvidia 390 series. When Bookworm came out, I was running Bullseye with this driver and never really had any graphical issues that I can remember. Upon upgrading to Bullseye, I eventually found out this driver was no longer available and I was stuck with nouveau. I was recommended the tesla 470 driver during the upgrade, but I never got it to work. According to Nvidia's official website GT 710 is supported up to 470 version. [1] I've never tried to install "tesla" flavor of nvidia-driver, so I can't suggest anything about it. When I needed a specific version I always build a simple backport [2] from "testing" repo, so I'd try to do the same for a 470.199.02 version, which is now available from "oldstable-proposed-updates" repo. You can also try the official package from Nvidia website, at least to test if 470 version works and solves your issue with freezing. The nouveau driver would be fine, since I don't do anything graphics-intensive like gaming and I get the bonus of being able to run Wayland, which is cool. Except that I started noticing constant freezes for no apparent reason. They usually take a few hours to happen, sometimes I can spend a day or maybe two without freezes, but they _keep happening_. I'm gonna spare you of the details of the effort I spent trying to investigate this problem, but what I found out is: * It happens in any of the kernels I have installed: 6.1, 6.0, 5.11, 4.9 * It happens in Plasma, and it doesn't matter if I'm running X11 or Wayland * It _seems_ not to happen under GNOME Wayland, but I think it happens under GNOME X11 * It appears to be related with screen sharing, because: o When I was using Plasma, I had the impression that the graphics froze way more often when I was sharing my screen o Screen sharing doesn't work on GNOME Wayland (maybe related to why it didn't freeze yet) o The one time where I tried to use GNOME X11, it froze immediately after I tried to share my screen * The kernel logs seem to indicate some missing firmware right before the graphics card freezes (and indeed some firmware is missing) I had issues very similar to your description. Even made a bug report [3] about it. I don't have any instability or "freezing" issues with recent kernel and driver versions, but I've also disabled hardware acceleration for my browser as a workaround and haven't actually checked if the issue is gone. Somehow it was all tied to video hardware acceleration and DE Compositor, which I kept disabled. I was able to repro the issue quite reliably, back then. I've thought this workaround was better than downgrading driver version to 416 and stick to it forever. Now I've upgraded system to Bookworm, and use 525.105.17 version, delaying update to an up-to-date version from stable, and haven't seen "Xid" errors or "freezes" for many months, Compositor is enabled, games and movies play without any issues. Screen sharing is essential for me to work, so this is really not a great situation to be in. For comparison, my laptop, which was also updated to Bookworm in the same day I updated this PC, had none of the problems I'm describing here, since it has an integrated intel graphics card. I appreciate that Nvidia cards can be very problematic and that the one card I own is really old, but I didn't have this problem until updating and I know this card can work just fine with the right driver. Unfortunately, right now, nouveau is not adequate for me to work, but the driver that does work is not officially available. What should I do? * Should I try updating to a newer kernel to see if nouveau got fixed? I haven't checked, but I think nouveau didn't had a commit in years. It is an abandon-ware for me. * Should I try installing the missing firmware? I'd try that, at least to see if it solves the issue. Keep in mind, non-free firmware was separated to another repo in Bookworm. [4] [1] https://www.nvidia.com/Download/driverResults.aspx/205995/en-us/ [2] https://wiki.debian.org/SimpleBackportCreation [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016542 [4] https://wiki.debian.org/SourcesList -- With kindest regards, Alexander. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄
Nvidia 390 driver no longer available for Bookworm; nouveau constantly freezes. Solutions?
Hello, all, (Please cc me when replying, I'm not subscribed to the mailing list) I have (according do lspci) a NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) graphics card. The correct proprietary driver for this card seems to be the Nvidia 390 series. When Bookworm came out, I was running Bullseye with this driver and never really had any graphical issues that I can remember. Upon upgrading to Bullseye, I eventually found out this driver was no longer available and I was stuck with nouveau. I was recommended the tesla 470 driver during the upgrade, but I never got it to work. The nouveau driver would be fine, since I don't do anything graphics-intensive like gaming and I get the bonus of being able to run Wayland, which is cool. Except that I started noticing constant freezes for no apparent reason. They usually take a few hours to happen, sometimes I can spend a day or maybe two without freezes, but they _keep happening_. I'm gonna spare you of the details of the effort I spent trying to investigate this problem, but what I found out is: * It happens in any of the kernels I have installed: 6.1, 6.0, 5.11, 4.9 * It happens in Plasma, and it doesn't matter if I'm running X11 or Wayland * It _seems_ not to happen under GNOME Wayland, but I think it happens under GNOME X11 * It appears to be related with screen sharing, because: o When I was using Plasma, I had the impression that the graphics froze way more often when I was sharing my screen o Screen sharing doesn't work on GNOME Wayland (maybe related to why it didn't freeze yet) o The one time where I tried to use GNOME X11, it froze immediately after I tried to share my screen * The kernel logs seem to indicate some missing firmware right before the graphics card freezes (and indeed some firmware is missing) Screen sharing is essential for me to work, so this is really not a great situation to be in. For comparison, my laptop, which was also updated to Bookworm in the same day I updated this PC, had none of the problems I'm describing here, since it has an integrated intel graphics card. I appreciate that Nvidia cards can be very problematic and that the one card I own is really old, but I didn't have this problem until updating and I know this card can work just fine with the right driver. Unfortunately, right now, nouveau is not adequate for me to work, but the driver that does work is not officially available. What should I do? * Should I try updating to a newer kernel to see if nouveau got fixed? * What it I try installing the 390 driver from Bullseye in my Bookworm installation? Would that cause any problems? * Should I try installing the missing firmware? * Any other ideas? Thank you for the help!
Re: [testing] passage du pilote proprio à nouveau
Le lundi 07 août 2023 à 08:59 +0200, Michel Verdier a écrit : > 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. Oui effectivement ça ne semble pas concerner ma carte qui est sur du gf116. > 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 Merci pour les liens. Mais rien de plus que ce que j'ai déjà. signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
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
Re: [testing] passage du pilote proprio à nouveau
Le dimanche 06 août 2023 à 19:54 +0200, didier gaumet a écrit : > Le 06/08/2023 à 16:19, Gaëtan Perrier a écrit : > > 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. > > - par effet de bord ton fonctionnement graphique peut être impacté par > un truc non graphique > - en gros il faut vérifier que ce qui reste ne sont que des paquets > *locaux* (hors dépôts Trixie mentionnés dans /etc/apt/sources.list et > /etc/apt/sources.list.d) parce qu'ils apparaissent aussi avec aptitude > search '~o'. Par contre, pas forcément, mais potentiellement, tous les > paquets qui sont réellement obsolètes ou d'une autre distro que Trixie > (stable, bookworm, unstable, sid, Ubuntu et autres) peuvent casser ton > installation. > > [...] > > 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 > > 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. Par exemple pour ga103 il y a juste: /lib/firmware/nvidia/ga103 /lib/firmware/nvidia/ga103/gr /lib/firmware/nvidia/ga103/gr/NET_img.bin /lib/firmware/nvidia/ga103/gr/fecs_bl.bin /lib/firmware/nvidia/ga103/gr/fecs_sig.bin /lib/firmware/nvidia/ga103/gr/gpccs_bl.bin /lib/firmware/nvidia/ga103/gr/gpccs_sig.bin Donc rien concernant ga103/sec2/* signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le dimanche 06 août 2023 à 20:04 +0200, didier gaumet a écrit : > 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 meilleurs > résultats qu'auparavant Les résultats sont exactement les mêmes, par contre depuis ce nettoyage je n'ai pas eu de nouveau crash. Je croise les doigts. > > => et surtout, si il était auparavant absent et que tu as installé le > paquet firmware-misc-nonfree, ça devrait au moins en partie pouvoir > expliquer tes problèmes et les résoudre. Non il était là depuis le début. signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à 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 meilleurs résultats qu'auparavant => et surtout, si il était auparavant absent et que tu as installé le paquet firmware-misc-nonfree, ça devrait au moins en partie pouvoir expliquer tes problèmes et les résoudre.
Re: [testing] passage du pilote proprio à nouveau
Le 06/08/2023 à 16:19, Gaëtan Perrier a écrit : 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. - par effet de bord ton fonctionnement graphique peut être impacté par un truc non graphique - en gros il faut vérifier que ce qui reste ne sont que des paquets *locaux* (hors dépôts Trixie mentionnés dans /etc/apt/sources.list et /etc/apt/sources.list.d) parce qu'ils apparaissent aussi avec aptitude search '~o'. Par contre, pas forcément, mais potentiellement, tous les paquets qui sont réellement obsolètes ou d'une autre distro que Trixie (stable, bookworm, unstable, sid, Ubuntu et autres) peuvent casser ton installation. [...] 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 tout ces firmwares semblent faire partie du paquet firmware-misc-non-free qui ne doit pas être installé chez toi, donc installe-le
Re: [testing] passage du pilote proprio à nouveau
Le dimanche 06 août 2023 à 16:19 +0200, Gaëtan Perrier a écrit : > > > > - 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 > ... > > 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. signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le samedi 05 août 2023 à 11:19 +0200, didier gaumet a écrit : > > 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 Je ferai ce test à mon retour de vacances fin août. > > - vérifier (apt policy) entre autres les versions de libc6 et libdrm* > installées sont les dernières disponibles libc6 je suis en 2.37-6 et sid en 2.37-7 libdrm 2.4.155-1 comme sid > > - chercher les paquets obsolètes (aptitude search '~o') rien concernant le système graphique. > > - 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 ... > > - 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 ;-) C'est possible mais jusqu'à maintenant ça fonctionnait très bien :) 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/ga106/acr/ucode_ahesasc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/acr/ucode_ahesasc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/acr/ucode_ahesasc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_asb.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/acr/ucode_asb.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/acr/ucode_asb.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/acr/ucode_asb.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_unload.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/acr/ucode_unload.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/acr/ucode_unload.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/acr/ucode_unload.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/nvdec/scrubber.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/nvdec/scrubber.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/nvdec/scrubber.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/nvdec/scrubber.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/sec2/hs_bl_sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/sec2/sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/sec2/image.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/sec2/desc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/sec2/hs_bl_sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/sec2/sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/sec2/image.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/sec2/desc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/sec2/hs_bl_sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/sec2/sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/sec2/image.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/sec2/desc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/hs_bl_sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/image.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/desc.bin for module nouveau signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
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 ;-)
Re: [testing] passage du pilote proprio à nouveau
Le vendredi 04 août 2023 à 21:32 +0200, Gaëtan Perrier a écrit : > Le vendredi 04 août 2023 à 20:21 +0200, Gaëtan Perrier a écrit : > > 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. > > Nouveau crash alors que j'étais sous xorg mais là je suis retourné à gdm > automatiquement. > Du coup j'ai une backtrace dans .local/share/xorg > > [ 1191.889] (EE) > [ 1191.889] (EE) Backtrace: > [ 1191.891] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) > [0x557e886e1d29] > [ 1191.892] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) > [0x7f5ce805a510] > [ 1191.893] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 > (pthread_key_delete+0x14c) > [0x7f5ce80a80fc] > [ 1191.893] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x12) > [0x7f5ce805a472] > [ 1191.894] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (abort+0xd3) > [0x7f5ce80444b2] > [ 1191.895] (EE) unw_get_proc_name failed: no unwind info found [-10] > [ 1191.895] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7f5ce80443d5] > [ 1191.896] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x42) > [0x7f5ce80533a2] > [ 1191.896] (EE) 7: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 > (nouveau_pushbuf_data+0xff) [0x7f5ce79f67ff] > [ 1191.897] (EE) 8: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 > (nouveau_pushbuf_data+0x63) [0x7f5ce79f6763] > [ 1191.897] (EE) 9: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 > (nouveau_pushbuf_data+0x17c) [0x7f5ce79f687c] > [ 1191.898] (EE) 10: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 > (nouveau_pushbuf_data+0x3f7) [0x7f5ce79f6af7] > [ 1191.898] (EE) 11: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 > (nouveau_pushbuf_data+0xb01) [0x7f5ce79f7201] > [ 1191.899] (EE) unw_get_proc_name failed: no unwind info found [-10] > [ 1191.899] (EE) 12: /usr/lib/xorg/modules/drivers/nouveau_drv.so (?+0x0) > [0x7f5ce7a21af8] > [ 1191.900] (EE) 13: /usr/lib/xorg/modules/libexa.so > (exaMoveOutPixmap+0x57b9) > [0x7f5ce79e2ae9] > [ 1191.900] (EE) 14: /usr/lib/xorg/modules/libexa.so > (exaMoveOutPixmap+0x5b21) > [0x7f5ce79e2e51] > [ 1191.901] (EE) 15: /usr/lib/xorg/Xorg (miCopyRegion+0x93) [0x557e886beea3] > [ 1191.901] (EE) 16: /usr/lib/xorg/Xorg (miDoCopy+0x466) [0x557e886bf5f6] > [ 1191.901] (EE) 17: /usr/lib/xorg/modules/libexa.so > (exaMoveOutPixmap+0x3d95) > [0x7f5ce79e10c5] > [ 1191.902] (EE) 18: /usr/lib/xorg/Xorg (DamageRegionAppend+0x359f) > [0x557e8865222f] > [ 1191.903] (EE) unw_get_proc_name failed: no unwind info found [-10] > [ 1191.903] (EE) 19: /usr/lib/xorg/modules/drivers/nouveau_drv.so (?+0x0) > [0x7f5ce7a0a5c1] > [ 1191.903] (EE) 20: /usr/lib/xorg/Xorg (DRIMoveBuffersHelper+0x14a8) > [0x557e8869aab8] > [ 1191.903] (EE) 21: /usr/lib/xorg/Xorg (DRI2CopyRegion+0x6e) > [0x557e8869b36e] > [ 1191.904] (EE) 22: /usr/lib/xorg/Xorg (DRI2GetParam+0xbf5) > [0x557e8869d785] > [ 1191.905] (EE) 23: /usr/lib/xorg/Xorg (SendErrorToClient+0x3d4) > [0x557e8856e734] > [ 1191.905] (EE) 24: /usr/lib/xorg/Xorg (InitFonts+0x3bc) [0x557e885726cc] > [ 1191.906] (EE) 25: /lib/x86_64-linux-gnu/libc.so.6 > (__libc_init_first+0x8a) > [0x7f5ce80456ca] > [ 1191.906] (EE) 26: /lib/x86_64-linux-gnu/libc.so.6 > (__libc_start_main+0x85) > [0x7f5ce8045785] > [ 1191.907] (EE) 27: /usr/lib/xorg/Xorg (_start+0x21) [0x557e8855bb71] > [ 1191.907] (EE) > [ 1191.907] (EE) > Fatal server error: > [ 1191.907] (EE) Caught signal 6 (Aborted). Server aborting > [ 1191.907] (EE) > [ 1191.907] (EE) > Please consult the The X.Org Foundation support > > Et des coredump dans journalctl: août 04 21:20:27 reveillon systemd[1]: Created slice system- systemd\x2dcoredump.slice - Slice /system/systemd-coredump. août 04 21:20:27 reveillon systemd[1]: Started systemd-coredump@0-13076-0.service - Process Core Dump (PID 13076/UID 0). août 04 21:20:28 reveillon systemd-coredump[13086]: [] Process 3340 (Xorg) of user 1000 dumped core. Module libsystemd.so.0 from deb systemd-254-1.amd64 Module libudev.so.1 from deb systemd-254-1.amd64 Stack trace of thread 3340: #0 0x7f5ce80a80fc __pthread_kill_implementation (libc.so.6 + 0x8a0fc) #1 0x7f5ce805a472 __GI_raise (libc.so.6 + 0x3c472) #2 0x7f5ce80444b2 __GI_abort (libc.so.6 + 0x264b2) #
Re: [testing] passage du pilote proprio à nouveau
Le vendredi 04 août 2023 à 20:21 +0200, Gaëtan Perrier a écrit : > 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. Nouveau crash alors que j'étais sous xorg mais là je suis retourné à gdm automatiquement. Du coup j'ai une backtrace dans .local/share/xorg [ 1191.889] (EE) [ 1191.889] (EE) Backtrace: [ 1191.891] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x557e886e1d29] [ 1191.892] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7f5ce805a510] [ 1191.893] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (pthread_key_delete+0x14c) [0x7f5ce80a80fc] [ 1191.893] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x12) [0x7f5ce805a472] [ 1191.894] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (abort+0xd3) [0x7f5ce80444b2] [ 1191.895] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 1191.895] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7f5ce80443d5] [ 1191.896] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x42) [0x7f5ce80533a2] [ 1191.896] (EE) 7: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 (nouveau_pushbuf_data+0xff) [0x7f5ce79f67ff] [ 1191.897] (EE) 8: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 (nouveau_pushbuf_data+0x63) [0x7f5ce79f6763] [ 1191.897] (EE) 9: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 (nouveau_pushbuf_data+0x17c) [0x7f5ce79f687c] [ 1191.898] (EE) 10: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 (nouveau_pushbuf_data+0x3f7) [0x7f5ce79f6af7] [ 1191.898] (EE) 11: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 (nouveau_pushbuf_data+0xb01) [0x7f5ce79f7201] [ 1191.899] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 1191.899] (EE) 12: /usr/lib/xorg/modules/drivers/nouveau_drv.so (?+0x0) [0x7f5ce7a21af8] [ 1191.900] (EE) 13: /usr/lib/xorg/modules/libexa.so (exaMoveOutPixmap+0x57b9) [0x7f5ce79e2ae9] [ 1191.900] (EE) 14: /usr/lib/xorg/modules/libexa.so (exaMoveOutPixmap+0x5b21) [0x7f5ce79e2e51] [ 1191.901] (EE) 15: /usr/lib/xorg/Xorg (miCopyRegion+0x93) [0x557e886beea3] [ 1191.901] (EE) 16: /usr/lib/xorg/Xorg (miDoCopy+0x466) [0x557e886bf5f6] [ 1191.901] (EE) 17: /usr/lib/xorg/modules/libexa.so (exaMoveOutPixmap+0x3d95) [0x7f5ce79e10c5] [ 1191.902] (EE) 18: /usr/lib/xorg/Xorg (DamageRegionAppend+0x359f) [0x557e8865222f] [ 1191.903] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 1191.903] (EE) 19: /usr/lib/xorg/modules/drivers/nouveau_drv.so (?+0x0) [0x7f5ce7a0a5c1] [ 1191.903] (EE) 20: /usr/lib/xorg/Xorg (DRIMoveBuffersHelper+0x14a8) [0x557e8869aab8] [ 1191.903] (EE) 21: /usr/lib/xorg/Xorg (DRI2CopyRegion+0x6e) [0x557e8869b36e] [ 1191.904] (EE) 22: /usr/lib/xorg/Xorg (DRI2GetParam+0xbf5) [0x557e8869d785] [ 1191.905] (EE) 23: /usr/lib/xorg/Xorg (SendErrorToClient+0x3d4) [0x557e8856e734] [ 1191.905] (EE) 24: /usr/lib/xorg/Xorg (InitFonts+0x3bc) [0x557e885726cc] [ 1191.906] (EE) 25: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) [0x7f5ce80456ca] [ 1191.906] (EE) 26: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) [0x7f5ce8045785] [ 1191.907] (EE) 27: /usr/lib/xorg/Xorg (_start+0x21) [0x557e8855bb71] [ 1191.907] (EE) [ 1191.907] (EE) Fatal server error: [ 1191.907] (EE) Caught signal 6 (Aborted). Server aborting [ 1191.907] (EE) [ 1191.907] (EE) Please consult the The X.Org Foundation support signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le vendredi 04 août 2023 à 11:06 +0200, didier gaumet a écrit : > 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. Oui moi aussi je trouve ça étonnant. Pourtant je n'ai plus de trace de paquets nvidia ... Ce qui est bizarre c'est que sous xorg ça fonctionne ... > > 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 Oui c'est bon. > > 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) Tout semble pourtant bon ... :( 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. signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le vendredi 04 août 2023 à 11:55 +0200, ajh-valmer a écrit :
> 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)
Oui j'en ai un
~$ cat /etc/X11/xorg.conf
Section "Device"
Identifier "MyGPU"
Driver "nouveau"
EndSection
signature.asc
Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
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) > > www.debian-fr.org/t/nvidia-installation-facile-du-pilote-libre-nouveau/17038
Re: [testing] passage du pilote proprio à nouveau
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)
Re: [testing] passage du pilote proprio à nouveau
Le vendredi 04 août 2023 à 01:20 +0200, Gaëtan Perrier a écrit : > 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 signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le jeudi 03 août 2023 à 11:50 +0200, ajh-valmer a écrit : > On Thursday 03 August 2023 03:57:07 Gaëtan Perrier wrote: > > Le mercredi 02 août 2023 à 13:31 +0200, ajh-valmer a écrit : > > > 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 : > C'est déjà un très bon point, mais je ne m'explique pas les "freeze". > > > > > Il y a une commande qui créé le /etc/X11/xorg.conf : > > X -configure ? > Sans doute ? à essayer... Par contre si j'ai bien compris faut la lancer sans que X soit démarré. > > j'ai trouvé ce tuto : > www.debian-fr.org/t/nvidia-installation-facile-du-pilote-libre-nouveau/17038 > Hope it helps... > Oui j'avais déjà du passer dessus. A+ Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
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. > > - 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/ vide > vérifies aussi que tu n'as pas des options de lancement de ton noyau > (kms, résolution vidéo) dans grub nada > > - 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) Possible, j'ai 20 ans d'historique ! :) Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
On Thursday 03 August 2023 03:57:07 Gaëtan Perrier wrote: > Le mercredi 02 août 2023 à 13:31 +0200, ajh-valmer a écrit : > > 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 : C'est déjà un très bon point, mais je ne m'explique pas les "freeze". > > > Il y a une commande qui créé le /etc/X11/xorg.conf : > X -configure ? Sans doute ? à essayer... j'ai trouvé ce tuto : www.debian-fr.org/t/nvidia-installation-facile-du-pilote-libre-nouveau/17038 Hope it helps...
Re: [testing] passage du pilote proprio à nouveau
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)
Re: [testing] passage du pilote proprio à nouveau
Le mercredi 02 août 2023 à 13:31 +0200, ajh-valmer a écrit : > 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 > 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. X -configure ? > 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 > ? Reconnue par les pilotes nvidia ? Je ne sais si les cartes supportées par les pilotes 525 sont compatibles avec ma carte mère qui date de 2011 ... Gaëtan
Re: [testing] passage du pilote proprio à nouveau
Le mercredi 02 août 2023 à 13:35 +0200, didier gaumet a écrit : > 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 Oui ce sont les pages que j'avais consultées. Mais je n'étais pas sûr que ce soit à jour. > > > 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? > Chez moi j'ai juste GNOME, GNOME Classique et GNOME Flashback (Metacity) ... Gaëtan
Re: [testing] passage du pilote proprio à nouveau
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?
Re: [testing] passage du pilote proprio à nouveau
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 ?
Re: gnome-shell erreur JSON (était Re: [testing] passage du pilote proprio à nouveau)
Le 02/08/2023 à 13:11, Gaëtan Perrier a écrit : Le mercredi 02 août 2023 à 10:20 +0200, didier gaumet a écrit : Le 01/08/2023 à 22:31, Gaëtan Perrier a écrit : J'aimerai bien mais je n'ai pas trouvé de conf où il manque de tun/tap ... J'y connais rien mais comment as-tu installé et paramétré OpenVPN? à la main, via un autre outil ou via Network-Manager? Via les paquets et c'est nordvpn qui l'utilise. Y a une page OpenVPN sur le wiki Debian j'ai jamais fait mais en gros ils ont l'air de dire que ça peut se paramétrer depuis Network-Manager. Je suis allé dans les paramètres pour créer un VPN: Gnome/Réseau/VPN/+/OpenVPN/Avancé/Configurer le type et le nom du périphérique réseau (je ne suis pas allé au bout, je n'utilise pas OpenVPN) sinon le wiki détaille comment faire ça à la main pour des tests. Je suppose que le wiki Archlinux doit aussi avoir un article intéressant là-dessus (pas cherché)
Re: gnome-shell erreur JSON (était Re: [testing] passage du pilote proprio à nouveau)
Le mercredi 02 août 2023 à 10:20 +0200, didier gaumet a écrit : > Le 01/08/2023 à 22:31, Gaëtan Perrier a écrit : > > > J'aimerai bien mais je n'ai pas trouvé de conf où il manque de > > tun/tap ... > > J'y connais rien mais comment as-tu installé et paramétré OpenVPN? à > la > main, via un autre outil ou via Network-Manager? > > Via les paquets et c'est nordvpn qui l'utilise.
Re: [testing] passage du pilote proprio à nouveau
Le mercredi 02 août 2023 à 11:01 +0200, didier gaumet a écrit : > > 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. 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 ... > > => (pure supposition) Ce qui voudrait dire que si on veut éviter les > ennuis 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) Je suis sur un desktop, aucun suspend aucune hibernation. > > - 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. 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 ... > > - 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 > Je vais regarder. > Bon courage :-) > Merci ;)
Re: [testing] passage du pilote proprio à nouveau
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 les ennuis 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 :-)
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 23:36, Gaëtan Perrier a écrit : 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 ... Je peux me tromper mais je pense que le message est seulement le système qui t'informe qu'il met fin au fonctionnement du service de géolocalisation. Et ça ne me paraît pas un truc au sujet duquel s'alarmer: prends l'exemple d'un smartphone: la géolocalisation ne fonctionne pas en permanence parce que 'est énergivore, donc n'est généralement activé qu'à la demande (manuelle ou automatique) et pour une période donnée (généralement aussi)
Re: gnome-shell erreur JSON (était Re: [testing] passage du pilote proprio à nouveau)
Le 01/08/2023 à 22:31, Gaëtan Perrier a écrit : J'aimerai bien mais je n'ai pas trouvé de conf où il manque de tun/tap ... J'y connais rien mais comment as-tu installé et paramétré OpenVPN? à la main, via un autre outil ou via Network-Manager?
Re: [testing] passage du pilote proprio à nouveau
Le mardi 01 août 2023 à 23:36 +0200, Gaëtan Perrier a écrit : > Le lundi 31 juillet 2023 à 12:49 +0200, Gaëtan Perrier a écrit : > > 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 ... > > Gaëtan Bon en fait ce n'était pas un vrai freeze. Je viens d'en avoir un et là y a des logs correspondant mais que je ne sais pas interpréter: août 02 01:07:39 reveillon kernel: INFO: task kworker/0:1H:26028 blocked for more than 120 seconds. août 02 01:07:39 reveillon kernel: Tainted: G OE 6.4.0-1- amd64 #1 Debian 6.4.4-1 août 02 01:07:39 reveillon kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. août 02 01:07:39 reveillon kernel: task:kworker/0:1H state:D stack:0 pid:26028 ppid:2 flags:0x4000 août 02 01:07:39 reveillon kernel: Workqueue: ttm ttm_bo_delayed_delete [ttm] août 02 01:07:39 reveillon kernel: Call Trace: août 02 01:07:39 reveillon kernel: août 02 01:07:39 reveillon kernel: __schedule+0x3df/0xb80 août 02 01:07:39 reveillon kernel: schedule+0x61/0xe0 août 02 01:07:39 reveillon kernel: schedule_timeout+0x151/0x160 août 02 01:07:39 reveillon kernel: dma_fence_default_wait+0x22a/0x280 août 02 01:07:39 reveillon kernel: ? __pfx_dma_fence_default_wait_cb+0x10/0x10 août 02 01:07:39 reveillon kernel: dma_fence_wait_timeout+0x10c/0x130 août 02 01:07:39 reveillon kernel: dma_resv_wait_timeout+0x7f/0xe0 août 02 01:07:39 reveillon kernel: ttm_bo_delayed_delete+0x2a/0x80 [ttm] août 02 01:07:39 reveillon kernel: process_one_work+0x1c7/0x3d0 août 02 01:07:39 reveillon kernel: worker_thread+0x51/0x390 août 02 01:07:39 reveillon kernel: ? __pfx_worker_thread+0x10/0x10 août 02 01:07:39 reveillon kernel: kthread+0xf7/0x130 août 02 01:07:39 reveillon kernel: ? __pfx_kthread+0x10/0x10 août 02 01:07:39 reveillon kernel: ret_from_fork+0x2c/0x50 août 02 01:07:39 reveillon kernel: août 02 01:07:39 reveillon kernel: INFO: task kworker/0:2H:26029 blocked for more than 120 seconds. août 02 01:07:39 reveillon kernel: Tainted: G OE 6.4.0-1- amd64 #1 Debian 6.4.4-1 août 02 01:07:39 reveillon kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. août 02 01:07:39 reveillon kernel: task:kworker/0:2H state:D stack:0 pid:26029 ppid:2 flags:0x4000 août 02 01:07:39 reveillon kernel: Workqueue: ttm ttm_bo_delayed_delete [ttm] août 02 01:07:39 reveillon kernel: Call Trace: août 02 01:07:39 reveillon kernel: août 02 01:07:39 reveillon kernel: __schedule+0x3df/0xb80 août 02 01:07:39 reveillon kernel: schedule+0x61/0xe0 août 02 01:07:39 reveillon kernel: schedule_timeout+0x151/0x160 août 02 01:07:39 reveillon kernel: dma_fence_default_wait+0x22a/0x280 août 02 01:07:39 reveillon kernel: ? __pfx_dma_fence_default_wait_cb+0x10/0x10 août 02 01:07:39 reveillon kernel: dma_fence_wait_timeout+0x10c/0x130 août 02 01:07:39 reveillon kernel: dma_resv_wait_timeout+0x7f/0xe0 août 02 01:07:39 reveillon kernel: ttm_bo_delayed_delete+0x2a/0x80 [ttm] août 02 01:07:39 reveillon kernel: process_one_work+0x1c7/0x3d0 août 02 01:07:39 reveillon kernel: worker_thread+0x51/0x390 août 02 01:07:39 reveillon kernel: ? __pfx_worker_thread+0x10/0x10 août 02 01:07:39 reveillon kernel: kthread+0xf7/0x130 août 02 01:07:39 reveillon kernel: ? __pfx_kthread+0x10/0x10 août 02 01:07:39 reveillon kernel: ret_from_fork+0x2c/0x50 août 02 01:07:39 reveillon kernel: août 02 01:07:39 reveillon kernel: INFO: task kworker/u8:0:26079 blocked for more than 120 seconds. août 02 01:07:39 reveillon kernel: Tainted: G OE 6.4.0-1- amd64 #1 Debian 6.4.4-1 août 02 01:07:39 reveillon kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. août 02 01:07:39 reveillon kernel: task:kworker/u8:0 state:D stack:0 pid:26079 ppid:2 flags:0x4000 août 02 01:07:39 reveillon kernel: Workqueue: events_unbound nv50_disp_atomic_commit_w
Re: [testing] passage du pilote proprio à nouveau
Le lundi 31 juillet 2023 à 12:49 +0200, Gaëtan Perrier a écrit : > 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 ... Gaëtan signature.asc Description: This is a digitally signed message part
Re: gnome-shell erreur JSON (était Re: [testing] passage du pilote proprio à nouveau)
Le mardi 01 août 2023 à 22:02 +0200, didier gaumet a écrit : > Le 01/08/2023 à 21:27, Gaëtan Perrier a écrit : > > > Probablement lié à un problème avec openvpn: > [...] > > ovpn-update-systemd-resolved[14381]: Options error: You must define TUN/TAP > > device (--dev) > [...] > > unexpected end of data at line 1 column 1 of the JSON data > > gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: > > unexpected end of data at line 1 column 1 of the JSON data > > Ce n'est qu'une impression mais l'erreur openvpn ne me semble pas liée à > l'erreur gnome-shell (je peux me tromper) > > de toute façon, tu peux essayer de solutionner le pb openvpn eb > paramétrant le périphérique TUN/TAP, si tu as de la chance ça résoudra > aussi le pb gnome-shell > J'aimerai bien mais je n'ai pas trouvé de conf où il manque de tun/tap ... Gaêtan signature.asc Description: This is a digitally signed message part
Re: gnome-shell erreur JSON (était Re: [testing] passage du pilote proprio à nouveau)
Le 01/08/2023 à 21:27, Gaëtan Perrier a écrit : Probablement lié à un problème avec openvpn: [...] ovpn-update-systemd-resolved[14381]: Options error: You must define TUN/TAP device (--dev) [...] unexpected end of data at line 1 column 1 of the JSON data gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data Ce n'est qu'une impression mais l'erreur openvpn ne me semble pas liée à l'erreur gnome-shell (je peux me tromper) de toute façon, tu peux essayer de solutionner le pb openvpn eb paramétrant le périphérique TUN/TAP, si tu as de la chance ça résoudra aussi le pb gnome-shell
gnome-shell erreur JSON (était Re: [testing] passage du pilote proprio à nouveau)
Le mardi 01 août 2023 à 13:55 +0200, didier gaumet a écrit : > Le 01/08/2023 à 13:52, didier gaumet a écrit : > > > 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) > > j'ai oublié de précisé que je n'avais pas ce genre d'erreur renvoyé par > journalctl > > Probablement lié à un problème avec openvpn: systemd[1]: openvpn@update-systemd-resolved.service: Scheduled restart job, restart counter is at 226. systemd[1]: Stopped openvpn@update-systemd-resolved.service - OpenVPN connection to update-systemd-resolved. systemd[1]: Starting openvpn@update-systemd-resolved.service - OpenVPN connection to update-systemd-resolved... ovpn-update-systemd-resolved[14381]: Options error: You must define TUN/TAP device (--dev) systemd[1]: openvpn@update-systemd-resolved.service: Main process exited, code=exited, status=1/FAILURE ovpn-update-systemd-resolved[14381]: Use --help for more information. systemd[1]: openvpn@update-systemd-resolved.service: Failed with result 'exit- code'. systemd[1]: Failed to start openvpn@update-systemd-resolved.service - OpenVPN connection to update-systemd-resolved. systemd[1]: openvpn@update-systemd-resolved.service: Scheduled restart job, restart counter is at 227. systemd[1]: Stopped openvpn@update-systemd-resolved.service - OpenVPN connection to update-systemd-resolved. systemd[1]: Starting openvpn@update-systemd-resolved.service - OpenVPN connection to update-systemd-resolved... ovpn-update-systemd-resolved[14404]: Options error: You must define TUN/TAP device (--dev) ovpn-update-systemd-resolved[14404]: Use --help for more information. systemd[1]: openvpn@update-systemd-resolved.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: openvpn@update-systemd-resolved.service: Failed with result 'exit- code'. systemd[1]: Failed to start openvpn@update-systemd-resolved.service - OpenVPN connection to update-systemd-resolved. gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 13:52, didier gaumet a écrit : 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) j'ai oublié de précisé que je n'avais pas ce genre d'erreur renvoyé par journalctl
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 12:14, Gaëtan Perrier a écrit : 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 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)
Re: [testing] passage du pilote proprio à nouveau
Le mardi 01 août 2023 à 12:14 +0200, didier gaumet a écrit : > 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 > oui c'est celà: gdm et systemd mais rien dans journalctl (voir une de mes autres réponses d'aujourd'hui) Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 12:14, didier gaumet a écrit : 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 et en l'occurrence, ceux de Xorg, normalement
Re: [testing] passage du pilote proprio à nouveau
Le 1 août 2023 Michel a écrit : > Effectivement, c'est LightDM que j'utilise ( avec XFCE ). Ah ba oui le postulat de base dont on parlait c'est lancer Xorg sans DE...
Re: [testing] passage du pilote proprio à nouveau
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 tty2Sl+ 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
Re: [testing] passage du pilote proprio à nouveau
Le lundi 31 juillet 2023 à 15:15 +0200, Erwan David a écrit : > 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 > 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 signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 11:51, Gaëtan Perrier a écrit : 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 L'emplacement local que j'ai cité pour du X11 rootless ne semble plus d'actualité. Dans un autre message, Michel Verdier a évoqué un endroit différent (~/.local/share/xorg/Xorg.0.log) et le wiki Archlinux va dans le même sens: https://wiki.archlinux.org/title/Xorg#General
Re: [testing] passage du pilote proprio à nouveau
Le mardi 01 août 2023 à 08:50 +0200, Michel Verdier a écrit : > 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). > 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 tty2Sl+ 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 Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le mardi 01 août 2023 à 07:03 +0200, Michel Verdier a écrit : > 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). > Chez ce fichier date du 1/4/2014 et contient ceci: # Xwrapper.config (Debian X Window System server wrapper configuration file) # # This file was generated by the post-installation script of the x11-common # package using values from the debconf database. # # See the Xwrapper.config(5) manual page for more information. # # This file is automatically updated on upgrades of the x11-common package # *only* if it has not been modified since the last upgrade of that package. # # If you have edited this file but would like it to be automatically updated # again, run the following command as root: # dpkg-reconfigure x11-common allowed_users=console Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le lundi 31 juillet 2023 à 15:13 +0200, Michel Verdier a écrit : > 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 Effectivement j'ai bien des fichiers log dans .local/share mais soit d'aujourd'hui soit du mois d'octobre ... Donc rien sur les dates des plantages et aucune erreur dans ceux d'aujourd'hui. Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
On Tuesday 01 August 2023 07:03:08 Michel Verdier wrote: > 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). Pour accéder aux configs de Xorg, il faut être root, ils sont dans /etc/X11/ Je ne me suis jamais préoccupé d'un mode Xorg en root ou user...
Re: [testing] passage du pilote proprio à nouveau
Le lundi 31 juillet 2023 à 14:00 +0200, 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)? 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 > Pour un Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou > /var/log/Xorg.0.log. Depuis le passage à nouveau les Xorg.*.log ne sont plus créés. > > 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/ > Pour la plongée je manque de souffle actuellement ;) Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 10:30, didier gaumet a écrit :
> 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
Effectivement, c'est LightDM que j'utilise ( avec XFCE ).
Re: [testing] passage du pilote proprio à nouveau
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
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 09:00, Michel Verdier a écrit : > 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 ).
Re: [testing] passage du pilote proprio à nouveau
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).
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 07:10, Michel Verdier a écrit : > 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). Non, j'ai seulement une ligne non commentée: allowed_users=console
Re: [testing] passage du pilote proprio à nouveau
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).
Re: [testing] passage du pilote proprio à nouveau
Le 31/07/2023 à 14:05, didier gaumet a écrit : 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. Merci à Michel, Michel et Erwan pour les précisions :-) Donc en cas de besoin chercher à tous les endroits mentionnés et pour éviter les erreurs, vérifier les dates incluses dans les logs pour vérifier qu'on regarde bien le bon fichier log, pas un vieux fichier log plus utilisé
Re: [testing] passage du pilote proprio à nouveau
Le 31/07/2023 à 15:20, Michel Verdier a écrit : > 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 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 ...
Re: [testing] passage du pilote proprio à nouveau
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 -- Erwan David
Re: [testing] passage du pilote proprio à nouveau
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
Re: [testing] passage du pilote proprio à nouveau
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.
Re: [testing] passage du pilote proprio à nouveau
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/
Re: [testing] passage du pilote proprio à nouveau
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 signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le lundi 31 juillet 2023 à 12:05 +0200, didier gaumet a écrit : > 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) ? > Alors finalement j'ai fait l'extraction depuis le pilote 340.xxx et ça me sort beaucoup plus de firmwares: ~$ ls /lib/firmware/nouveau/ nv106_fuc084nv98_vp nvc0_bsp nvcf_fuc085 nvf1_fuc084 nv106_fuc085nva3_bsp nvc0_fuc084 nvcf_fuc086 nvf1_fuc085 nv106_fuc086nva3_fuc084 nvc0_fuc085 nvd7_fuc084 nvf1_fuc086 nv108_fuc084nva3_fuc085 nvc0_fuc086 nvd7_fuc085 vuc-h264-0 nv108_fuc085nva3_fuc086 nvc0_ppp nvd7_fuc086 vuc-mpeg12-0 nv108_fuc086nva3_ppp nvc0_vp nvd9_fuc084 vuc-mpeg4-0 nv84_bspnva3_vp nvc1_fuc084 nvd9_fuc085 vuc-mpeg4-1 nv84_bsp-h264 nva5_fuc084 nvc1_fuc085 nvd9_fuc086 vuc-vc1-0 nv84_vp nva5_fuc085 nvc1_fuc086 nve0_bsp vuc-vc1-1 nv84_vp-h264-1 nva5_fuc086 nvc3_fuc084 nve0_vp vuc-vc1-2 nv84_vp-h264-2 nva8_fuc084 nvc3_fuc085 nve4_fuc084 vuc-vp3-h264-0 nv84_vp-mpeg12 nva8_fuc085 nvc3_fuc086 nve4_fuc085 vuc-vp3-mpeg12-0 nv84_vp-vc1-1 nva8_fuc086 nvc4_fuc084 nve4_fuc086 vuc-vp3-vc1-0 nv84_vp-vc1-2 nvaa_fuc084 nvc4_fuc085 nve6_fuc084 vuc-vp3-vc1-1 nv84_vp-vc1-3 nvaa_fuc085 nvc4_fuc086 nve6_fuc085 vuc-vp3-vc1-2 nv84_xuc00f nvaa_fuc086 nvc8_fuc084 nve6_fuc086 vuc-vp4-h264-0 nv84_xuc103 nvac_fuc084 nvc8_fuc085 nve7_fuc084 vuc-vp4-mpeg12-0 nv98_bspnvac_fuc085 nvc8_fuc086 nve7_fuc085 vuc-vp4-mpeg4-0 nv98_fuc084 nvac_fuc086 nvce_fuc084 nve7_fuc086 vuc-vp4-mpeg4-1 nv98_fuc085 nvaf_fuc084 nvce_fuc085 nvf0_fuc084 vuc-vp4-vc1-0 nv98_fuc086 nvaf_fuc085 nvce_fuc086 nvf0_fuc085 vuc-vp4-vc1-1 nv98_pppnvaf_fuc086 nvcf_fuc084 nvf0_fuc086 vuc-vp4-vc1-2 Du coup en user vainfo me retourne : ~$ vainfo libva info: VA-API version 1.19.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so libva info: Found init function __vaDriverInit_1_17 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.19 (libva 2.12.0) vainfo: Driver version: Mesa Gallium driver 22.3.6 for NVCF vainfo: Supported profile and entrypoints VAProfileMPEG2Simple: VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main: VAEntrypointVLD VAProfileVC1Advanced: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264Main : VAEntrypointVLD VAProfileH264High : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc et vdpauinfo retourne toujours en user: ~$ vdpauinfo display: :1 screen: 0 API version: 1 Information string: G3DVL VDPAU Driver Shared Library version 1.0 Video surface: name width height types --- 42016384 16384 NV12 YV12 42216384 16384 UYVY YUYV 44416384 16384 Y8U8V8A8 V8U8Y8A8 420_16 16384 16384 422_16 16384 16384 444_16 16384 16384 Decoder capabilities: namelevel macbs width height MPEG1 0 8192 2048 2048 MPEG2_SIMPLE3 8192 2048 2048 MPEG2_MAIN 3 8192 2048 2048 H264_BASELINE 41 8192 2048 2048 H264_MAIN 41 8192 2048 2048 H264_HIGH 41 8192 2048 2048 VC1_SIMPLE 1 8190 2048 2048 VC1_MAIN2 8190 2048 2048 VC1_ADVANCED4 8190 2048 2048 MPEG4_PART2_SP 3 8192 2048 2048 MPEG4_PART2_ASP 5 8192 2048 2048 DIVX4_QMOBILE --- not supported --- DIVX4_MOBILE --- not supported --- DIVX4_HOME_THEATER --- not supported --- DIVX4_HD_1080P --- not supported --- DIVX5_QMOBILE --- not supported --- DIVX5_MOBILE --- not supported --- DIVX5_HOME_THEATER --- not supported --- DIVX5_HD_1080P --- not supported --- H264_CONSTRAINED_BASELINE 41 8192 2048 2048 H264_EXTENDED --- not supported --- H264_PROGRESSIVE_HIGH --- not supported --- H264_CONSTRAINED_HIGH --- not supported --- H264_HIGH_444_PREDICTIVE --- not supported --- VP9_PROFILE_0
Re: [testing] passage du pilote proprio à nouveau
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) ?
Re: [testing] passage du pilote proprio à nouveau
Le lundi 31 juillet 2023 à 10:00 +0200, didier gaumet a écrit : > 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. A ce que j'ai compris le support "nouveau noyau" s'arrête au 6.3. Quand le 6.4 est arrivé sur ma machine son installation a échoué à cause des pilotes nvidia ... C'est ce qui a motivé mon passage à Nouveau. > > 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. Ma perception est effectivement différente. ;) Pour moi stable c'est bien sur un serveur. Pour une machine de bureau les appli ne suivent pas assez vite même avec les backports. Après entre testing et sid je n'ai pas vraiment d'avis mais comme ça doit bien faire 20 ans que je tourne en testing (+ qq morceaux sid) je n'ai jamais changé. > > > 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 C'était bien un purge qui a été réalisé. > > > J'ai essayé de suivre cette page (qui ne semble pas à jour) pour récupérer > > les > > firmware du pilote 390.157. > > quelle page? oups j'ai oublié le lien :-( https://nouveau.freedesktop.org/VideoAcceleration.html > > > 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 > A ce que j'ai compris les gsp ne concernent que les cartes depuis l'archi Turing, la mienne est une Fermi bien plus vieille. Pour misc-nonfree oui j'ai essayé mais je n'ai pas les décodeurs. 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 ... A+ Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
On Monday 31 July 2023 00:20:58 Gaëtan Perrier wrote: > 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. Le pilote 390.157 proposé par Nvidia sur son site est en version 32 bits : www.nvidia.fr/Download/driverResults.aspx/196247/fr Pour créer un pilote Nouveau, il faut semble t-il un xorg.conf. J'ai tenté il y a peu, mais résolution maximum 1024X768, trop insuffisant, mais ça m'a permis d'avoir le mode graphique pour rechercher une solution. Désolé de ne pas t'aider plus...
Re: [testing] passage du pilote proprio à nouveau
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
[testing] passage du pilote proprio à nouveau
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: /lib/firmware/nouveau]# ls vuc-h264-0 vuc-vc1-0 vuc-vc1-1 vuc-vc1-2 vuc-vp4-h264-0 vuc-vp4-vc1-0 vuc-vp4-vc1-1 vuc-vp4-vc1-2 Après reboot en root j'obtiens les résultats en ci-dessous pour vainfo et vdpauinfo. Mais en user j'obtiens un résultat différent notamment pour vdpauinfo où les decoder ne sont pas présent ci-dessous également glxinfo est similaire dans les 2 cas. Bref je suis un peu perdu et les infos sur https://nouveau.freedesktop.org semblent vraiment pas à jour :( Qu'en pensez ? Qu'est-ce que j'ai loupé ? Gaëtan root display: :1 screen: 0 API version: 1 Information string: G3DVL VDPAU Driver Shared Library version 1.0 Video surface: name width height types --- 42016384 16384 NV12 YV12 42216384 16384 UYVY YUYV 44416384 16384 Y8U8V8A8 V8U8Y8A8 420_16 16384 16384 422_16 16384 16384 444_16 16384 16384 Decoder capabilities: namelevel macbs width height MPEG1 --- not supported --- MPEG2_SIMPLE --- not supported --- MPEG2_MAIN --- not supported --- H264_BASELINE --- not supported --- H264_MAIN --- not supported --- H264_HIGH --- not supported --- VC1_SIMPLE --- not supported --- VC1_MAIN --- not supported --- VC1_ADVANCED --- not supported --- MPEG4_PART2_SP --- not supported --- MPEG4_PART2_ASP--- not supported --- DIVX4_QMOBILE --- not supported --- DIVX4_MOBILE --- not supported --- DIVX4_HOME_THEATER --- not supported --- DIVX4_HD_1080P --- not supported --- DIVX5_QMOBILE --- not supported --- DIVX5_MOBILE --- not supported --- DIVX5_HOME_THEATER --- not supported --- DIVX5_HD_1080P --- not supported --- H264_CONSTRAINED_BASELINE --- not supported --- H264_EXTENDED --- not supported --- H264_PROGRESSIVE_HIGH --- not supported --- H264_CONSTRAINED_HIGH --- not supported --- H264_HIGH_444_PREDICTIVE --- not supported --- VP9_PROFILE_0 --- not supported --- VP9_PROFILE_1 --- not supported --- VP9_PROFILE_2 --- not supported --- VP9_PROFILE_3 --- not supported --- HEVC_MAIN --- not supported --- HEVC_MAIN_10 --- not supported --- HEVC_MAIN_STILL--- not supported --- HEVC_MAIN_12 --- not supported --- HEVC_MAIN_444 --- not supported --- HEVC_MAIN_444_10 --- not supported --- HEVC_MAIN_444_12 --- not supported --- AV1_MAIN --- not supported --- AV1_HIGH --- not supported --- AV1_PROFESSIONAL --- not supported --- Output surface: name width height nat types B8G8R8A8 16384 16384y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 P010 P016 A4I4 I4A4 A8I8 I8A8 R8G8B8A8 16384 16384y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 P010 P016 A4I4 I4A4 A8I8 I8A8 R10G10B10A2 16384 16384y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 P010 P016 A4I4 I4A4 A8I8 I8A8 B10G10R10A2 16384 16384y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 P010 P016 A4I4 I4A4 A8I8 I8A8 Bitmap surface: name width height -- B8G8R8A8 16384 16384 R8G8B8A8 16384 16384 R10G10B10A2 16384 16384 B10G10R10A2 16384 16384 A8 16384 16384 Video mixer: feature namesup DEINTERLACE_TEMPORAL y DEINTERLACE_TEMPORAL_SPATIAL - INVERSE_TELECINE - NOISE_REDUCTION y SHARPNESSy LUMA_KEY y HIGH QUALITY SCALING - L1y HIGH QUALITY SCALING - L2- HIGH QUALITY SCALING - L3
Re: nvidia ou nouveau sur bookworm ?
Le 27/06/23 à 22:15, Étienne Mollier a écrit : > J'allais proposer la troisième option qui consisterait à > installer le paquet nvidia-open-kernel-dkms, de la section > contrib… :) Merci de signaler l'alternative… > > … mais la GTX 1060 Mobile n'apparait pas dans la liste des > matériels supportés [1]. :( > > [1] : > https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/README.md#compatible-gpus …même si ce sera pas pour cette carte. > Du coup, oui, il vaut mieux installer xserver-xorg-video-nvidia > et nvidia-kernel-dkms pour remplacer nouveau si on est peu > regardant sur l'usage de ce pilotes propriétaires, et que le > pilote nouveau ne permet pas de travailler confortablement. > Tout du moins, ça vaut le coup d'essayer. En dehors du côté éthique, 50 paquets et 500Mo, ça fait bcp pour gérer une carte vidéo… Au redémarrage, ça ne change rien… J'ai débranché l'écran en VGA, idem, les réglages d'anti-aliasing (anti-crénelage) semblent complètement ignorés. En plus de cinnamont, j'ai testé aussi avec gnome3 (là il ne veut pas mettre mon écran en paysage, en me disant que c'est probablement une limitation matérielle) et cinnamon software rendering, pas mieux… Il me reste à creuser cette histoire d'anti-aliasing, ça me rappelle vaguement qqchose, il me semble qu'il y a pas mal d'années j'avais dû bricoler un truc dans la conf xorg (mais c'était bien avant wayland et nouveau), je vais creuser, si vous avez des suggestions n'hésitez pas. -- Daniel Partout où l'esprit humain a la moindre possibilité de connaître, il y a un problème légitime pour la science Karl Pearson
Re: nvidia ou nouveau sur bookworm ?
Bonjour Daniel, Daniel Caillibaud, on 2023-06-27: > Bonjour, > > Sur un nouveau PC avec une carte GP106M (GeForce GTX 1060 Mobile) fraîchement > installé avec > bookworm, et je me demandais s'il valait mieux installer > xserver-xorg-video-nvidia et nvidia-kernel-dkms pour remplacer nouveau (mis > par l'installeur). J'allais proposer la troisième option qui consisterait à installer le paquet nvidia-open-kernel-dkms, de la section contrib… :) … mais la GTX 1060 Mobile n'apparait pas dans la liste des matériels supportés [1]. :( [1] : https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/README.md#compatible-gpus Du coup, oui, il vaut mieux installer xserver-xorg-video-nvidia et nvidia-kernel-dkms pour remplacer nouveau si on est peu regardant sur l'usage de ce pilotes propriétaires, et que le pilote nouveau ne permet pas de travailler confortablement. Tout du moins, ça vaut le coup d'essayer. Bonne journée, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. On air: Bader Nana - Mercenaries signature.asc Description: PGP signature
nvidia ou nouveau sur bookworm ?
Bonjour, Sur un nouveau PC avec une carte GP106M (GeForce GTX 1060 Mobile) fraîchement installé avec bookworm, et je me demandais s'il valait mieux installer xserver-xorg-video-nvidia et nvidia-kernel-dkms pour remplacer nouveau (mis par l'installeur). J'ai un affichage pas terrible avec 3 écrans - écran du PC 1920×1080 : affichage passable, caractères un peu crénelés - écran 1200×1920 (portrait) : couleurs pas géniales (pas grave pour moi) et polices toutes baveuses (nettement plus gênant), mais là je soupçonne la connectique, y'a un adaptateur mini display port vers VGA, c'est probablement lui le fautif, faut que je me procure du mini DP => DVI - écran 2560×1440 branché en HDMI : polices très crenelées, surtout dans le terminal (moins dans un navigateur) J'ai testé différents réglages dans paramètres système / Sélection de polices (sous cinnamon), mais je ne vois aucune différences, et je trouve ça louche, car normalement entre "optimisation : aucun" et "optimisation : complète" la différence est flagrante, donc j'ai l'impression qu'il n'y a aucun anti-aliasing, quel que soit ce réglage. Un conseil ? Merci PS: lshw me dit produit: GP106M [GeForce GTX 1060 Mobile] fabriquant: NVIDIA Corporation identifiant matériel: 0 information bus: pci@:01:00.0 nom logique: /dev/fb0 version: a1 bits: 64 bits horloge: 33MHz fonctionnalités: pm msi pciexpress vga_controller bus_master cap_list rom fb configuration: depth=32 driver=nouveau latency=0 resolution=2560,1440 -- Daniel
[cartes Nvidia, Unstable] Evitez d'utiliser le pilote Nouveau avec le noyau 6.3
Phoronix rapporte des soucis avec le pilote nouveau utilisé en conjonction avec un noyau Linux 6.3: https://www.phoronix.com/news/Avoid-Nouveau-Linux-6.3
Re: package libxnvctrl0 installed by xfce, but nouveau is installed
On 2023-04-05 15:15:59 +0200, zithro wrote: > > On 2023-04-04 18:27:59 +0200, zithro wrote: > > > Unfortunately, "libxnvctrl0" is a dependency for "xfce4-sensors-plugin" > : > > > > > > apt show xfce4-sensors-plugin > > > Depends: libxnvctrl0 > > > > > > So marking the packages provides the exact same output as above. > > > > > > Should I report a bug in the "xfce4-sensors-plugin" package ? > > > > No, the dependency is normal. If you look at the source, there's > > a file lib/nvidia.cc that uses libxnvctrl0: [...] > > Hence the dependency. > > Thanks for the hints ! > What's strange is that in the sensors plugin GUI, the "sensor type" > concerning my GPU is called "nouveau-2000". I suppose that the plugin supports various drivers. Since you are using nouveau, it outputs a name related to nouveau. > I don't have any other sensor source coming from "*nvidia*" or "*nv*". > I'm wondering how this lib can work without the official driver, and if it's > not related to the nouveau bug I have ? I suppose that the plugin calls a function of this lib only if it detects that the nvidia driver is used. But even if the plugin doesn't use this lib, the lib must be present so that it can be linked against the plugin at load time (an alternative way for the plugin would be to use dlopen(), in which case the lib would not be needed, but I suppose that this is not the method used by the plugin). -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: package libxnvctrl0 installed by xfce, but nouveau is installed
> On 2023-04-04 18:27:59 +0200, zithro wrote:
> > Unfortunately, "libxnvctrl0" is a dependency for
"xfce4-sensors-plugin" :
> >
> > apt show xfce4-sensors-plugin
> > Depends: libxnvctrl0
> >
> > So marking the packages provides the exact same output as above.
> >
> > Should I report a bug in the "xfce4-sensors-plugin" package ?
>
> No, the dependency is normal. If you look at the source, there's
> a file lib/nvidia.cc that uses libxnvctrl0:
>
> if (XNVCTRLQueryTargetAttribute (nvidia_sensors_display.display,
> NV_CTRL_TARGET_TYPE_GPU,
> idx_gpu,
> 0,
> NV_CTRL_GPU_CORE_TEMPERATURE,
> )) {
> result = temperature;
> }
> [...]
> if (XNVCTRLQueryExtension (nvidia_sensors_display.display,
, )) {
> XNVCTRLQueryTargetCount (nvidia_sensors_display.display,
> NV_CTRL_TARGET_TYPE_GPU,
> _gpus);
> }
> [...]
> if (XNVCTRLQueryTargetStringAttribute
(nvidia_sensors_display.display,
> NV_CTRL_TARGET_TYPE_GPU,
> idx_gpu,
> 0,
> NV_CTRL_STRING_PRODUCT_NAME,
> )) {
> g_assert (gpuname != NULL);
> feature->devicename = gpuname; /* "it is the caller's
responsibility to free ..." */
> }
>
> Hence the dependency.
Thanks for the hints !
What's strange is that in the sensors plugin GUI, the "sensor type"
concerning my GPU is called "nouveau-2000".
I don't have any other sensor source coming from "*nvidia*" or "*nv*".
I'm wondering how this lib can work without the official driver, and if
it's not related to the nouveau bug I have ?
Re: package libxnvctrl0 installed by xfce, but nouveau is installed
On 2023-04-04 18:27:59 +0200, zithro wrote:
> Unfortunately, "libxnvctrl0" is a dependency for "xfce4-sensors-plugin" :
>
> apt show xfce4-sensors-plugin
> Depends: libxnvctrl0
>
> So marking the packages provides the exact same output as above.
>
> Should I report a bug in the "xfce4-sensors-plugin" package ?
No, the dependency is normal. If you look at the source, there's
a file lib/nvidia.cc that uses libxnvctrl0:
if (XNVCTRLQueryTargetAttribute (nvidia_sensors_display.display,
NV_CTRL_TARGET_TYPE_GPU,
idx_gpu,
0,
NV_CTRL_GPU_CORE_TEMPERATURE,
)) {
result = temperature;
}
[...]
if (XNVCTRLQueryExtension (nvidia_sensors_display.display, ,
)) {
XNVCTRLQueryTargetCount (nvidia_sensors_display.display,
NV_CTRL_TARGET_TYPE_GPU,
_gpus);
}
[...]
if (XNVCTRLQueryTargetStringAttribute (nvidia_sensors_display.display,
NV_CTRL_TARGET_TYPE_GPU,
idx_gpu,
0,
NV_CTRL_STRING_PRODUCT_NAME,
)) {
g_assert (gpuname != NULL);
feature->devicename = gpuname; /* "it is the caller's
responsibility to free ..." */
}
Hence the dependency.
--
Vincent Lefèvre - Web:
Re: Re: package libxnvctrl0 installed by xfce, but nouveau is installed
Thanks, I'll report the bug in BTS then
Re: package libxnvctrl0 installed by xfce, but nouveau is installed
On 04 Apr 2023 16:56, Jeffrey Walton wrote: On Tue, Apr 4, 2023 at 9:18 AM zithro wrote: I have a bug with the nouveau driver shown in dmesg, so I looked up for solutions. On freedesktop.org, they say to remove everything concerning nvidia first, and only installing/using "nouveau" packages. On my system, I found the package "libxnvctrl0" (by nvidia) which was installed by xfce. If I try to remove "libxnvctrl0", it wants to remove "xfce4-goodies" and "xfce4-sensors-plugin". Then, many packages are marked as "autoremove" (xfce-*, ristretto, ...). Is that normal that xfce packages rely on an official nvidia library, even when using nouveau ? What should I do ? Thanks, have a nice day ! PS: I'm using an up-to-date Debian stable (uname: Linux debian 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux). Output of "apt purge libxnvctrl0 --dry-run" : The following packages were automatically installed and are no longer required: libqrencode4 ristretto xfce4-battery-plugin xfce4-clipman xfce4-clipman-plugin xfce4-cpufreq-plugin xfce4-cpugraph-plugin xfce4-datetime-plugin xfce4-dict xfce4-diskperf-plugin xfce4-fsguard-plugin xfce4-genmon-plugin xfce4-mailwatch-plugin xfce4-netload-plugin xfce4-places-plugin xfce4-screenshooter xfce4-smartbookmark-plugin xfce4-systemload-plugin xfce4-taskmanager xfce4-timer-plugin xfce4-verve-plugin xfce4-wavelan-plugin xfce4-weather-plugin xfce4-whiskermenu-plugin xfce4-xkb-plugin Use 'apt autoremove' to remove them. The following packages will be REMOVED: libxnvctrl0* xfce4-goodies* xfce4-sensors-plugin* 0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded. Purg xfce4-goodies [4.14.0] Purg xfce4-sensors-plugin [1.3.0-3] Purg libxnvctrl0 [470.141.03-1~deb11u1] I think you can take one of two actions. First, if you have not removed the recommended packages that are no longer needed, then use apt-mark to change them from auto to manual. Something like: apt-mark manual xfce4-goodies xfce4-sensors-plugin libxnvctrl0 Second, if you have removed them, then manually install them. Apt should leave them alone after that. Something like: apt-get install xfce4-goodies xfce4-sensors-plugin libxnvctrl0 Thank you for your quick answer ! Unfortunately, "libxnvctrl0" is a dependency for "xfce4-sensors-plugin" : apt show xfce4-sensors-plugin Depends: libxnvctrl0 So marking the packages provides the exact same output as above. Should I report a bug in the "xfce4-sensors-plugin" package ?
Re: package libxnvctrl0 installed by xfce, but nouveau is installed
On 2023-04-04 15:00:11 +0200, zithro wrote: > I have a bug with the nouveau driver shown in dmesg, so I looked up for > solutions. > On freedesktop.org, they say to remove everything concerning nvidia first, > and only installing/using "nouveau" packages. > On my system, I found the package "libxnvctrl0" (by nvidia) which was > installed by xfce. > If I try to remove "libxnvctrl0", it wants to remove "xfce4-goodies" and > "xfce4-sensors-plugin". > Then, many packages are marked as "autoremove" (xfce-*, ristretto, ...). > Is that normal that xfce packages rely on an official nvidia library, even > when using nouveau ? Perhaps. It is possible that some tools provided by these xfce packages are linked against this library, so that a dependency is required (otherwise, these tools would not be able to run, even if they will not have to call functions from this library in your case, e.g. when using nouveau). > What should I do ? Just keep this package installed. Since this is just a library package (as you can check with "dpkg -L libxnvctrl0"), it should not hurt. IMHO, when they say to remove everything concerning nvidia first, they probably mean packages that contain drivers and/or daemons (and possibly some binaries), as they could be loaded/executed by default. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: package libxnvctrl0 installed by xfce, but nouveau is installed
On Tue, Apr 4, 2023 at 9:18 AM zithro wrote:
>
> I have a bug with the nouveau driver shown in dmesg, so I looked up for
> solutions.
> On freedesktop.org, they say to remove everything concerning nvidia
> first, and only installing/using "nouveau" packages.
> On my system, I found the package "libxnvctrl0" (by nvidia) which was
> installed by xfce.
> If I try to remove "libxnvctrl0", it wants to remove "xfce4-goodies" and
> "xfce4-sensors-plugin".
> Then, many packages are marked as "autoremove" (xfce-*, ristretto, ...).
> Is that normal that xfce packages rely on an official nvidia library,
> even when using nouveau ?
>
> What should I do ?
>
> Thanks, have a nice day !
>
> PS:
> I'm using an up-to-date Debian stable (uname: Linux debian
> 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux).
>
> Output of "apt purge libxnvctrl0 --dry-run" :
>
> The following packages were automatically installed and are no longer
> required:
>libqrencode4 ristretto xfce4-battery-plugin xfce4-clipman
> xfce4-clipman-plugin xfce4-cpufreq-plugin xfce4-cpugraph-plugin
>xfce4-datetime-plugin xfce4-dict xfce4-diskperf-plugin
> xfce4-fsguard-plugin xfce4-genmon-plugin xfce4-mailwatch-plugin
>xfce4-netload-plugin xfce4-places-plugin xfce4-screenshooter
> xfce4-smartbookmark-plugin xfce4-systemload-plugin
>xfce4-taskmanager xfce4-timer-plugin xfce4-verve-plugin
> xfce4-wavelan-plugin xfce4-weather-plugin
>xfce4-whiskermenu-plugin xfce4-xkb-plugin
> Use 'apt autoremove' to remove them.
> The following packages will be REMOVED:
>libxnvctrl0* xfce4-goodies* xfce4-sensors-plugin*
> 0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded.
> Purg xfce4-goodies [4.14.0]
> Purg xfce4-sensors-plugin [1.3.0-3]
> Purg libxnvctrl0 [470.141.03-1~deb11u1]
I think you can take one of two actions.
First, if you have not removed the recommended packages that are no
longer needed, then use apt-mark to change them from auto to manual.
Something like:
apt-mark manual xfce4-goodies xfce4-sensors-plugin libxnvctrl0
Second, if you have removed them, then manually install them. Apt
should leave them alone after that. Something like:
apt-get install xfce4-goodies xfce4-sensors-plugin libxnvctrl0
Also see the apt-mark(8) man page:
APT-MARK(8) APT APT-MARK(8)
NAME
apt-mark - show, set and unset various settings for a package
SYNOPSIS
apt-mark {-f=filename | {auto | manual} pkg... |
{showauto | showmanual} [pkg...] } | {-v | --version} |
{-h | --help}
apt-mark {hold | unhold | install | remove | purge} pkg... |
{showhold | showinstall | showremove | showpurge} [pkg...]
DESCRIPTION
apt-mark can be used as a unified front-end to set various settings for
a package, such as marking a package as being automatically/manually
installed or changing dpkg selections such as hold, install, deinstall
and purge which are respected e.g. by apt-get dselect-upgrade or
aptitude.
Jeff
package libxnvctrl0 installed by xfce, but nouveau is installed
Hello, I have a bug with the nouveau driver shown in dmesg, so I looked up for solutions. On freedesktop.org, they say to remove everything concerning nvidia first, and only installing/using "nouveau" packages. On my system, I found the package "libxnvctrl0" (by nvidia) which was installed by xfce. If I try to remove "libxnvctrl0", it wants to remove "xfce4-goodies" and "xfce4-sensors-plugin". Then, many packages are marked as "autoremove" (xfce-*, ristretto, ...). Is that normal that xfce packages rely on an official nvidia library, even when using nouveau ? What should I do ? Thanks, have a nice day ! PS: I'm using an up-to-date Debian stable (uname: Linux debian 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux). Output of "apt purge libxnvctrl0 --dry-run" : The following packages were automatically installed and are no longer required: libqrencode4 ristretto xfce4-battery-plugin xfce4-clipman xfce4-clipman-plugin xfce4-cpufreq-plugin xfce4-cpugraph-plugin xfce4-datetime-plugin xfce4-dict xfce4-diskperf-plugin xfce4-fsguard-plugin xfce4-genmon-plugin xfce4-mailwatch-plugin xfce4-netload-plugin xfce4-places-plugin xfce4-screenshooter xfce4-smartbookmark-plugin xfce4-systemload-plugin xfce4-taskmanager xfce4-timer-plugin xfce4-verve-plugin xfce4-wavelan-plugin xfce4-weather-plugin xfce4-whiskermenu-plugin xfce4-xkb-plugin Use 'apt autoremove' to remove them. The following packages will be REMOVED: libxnvctrl0* xfce4-goodies* xfce4-sensors-plugin* 0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded. Purg xfce4-goodies [4.14.0] Purg xfce4-sensors-plugin [1.3.0-3] Purg libxnvctrl0 [470.141.03-1~deb11u1] This is the nouveau bug in dmesg : [ cut here ] WARNING: CPU: 0 PID: 2205 at drivers/gpu/drm/nouveau/nvif/vmm.c:68 nvif_vmm_put+0x6e/0x80 [nouveau] Modules linked in: nfnetlink xen_acpi_processor xen_gntdev xen_evtchn xenfs xen_privcmd bridge stp llc crc32_pclmul ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio aesni_intel libaes crypto_simd snd_hda_codec_hdmi snd_hda_intel cryptd snd_intel_dspcfg glue_helper soundwire_intel soundwire_generic_allocation snd_soc_core wmi_bmof snd_compress soundwire_cadence pcspkr k10temp snd_hda_codec uas joydev snd_hda_core usb_storage sp5100_tco ccp snd_hwdep watchdog soundwire_bus i2c_piix4 rng_core snd_pcm snd_timer snd soundcore cxgb3 r8169 mdio realtek 3c59x mdio_devres libphy mii sg nvme nvme_core drivetemp fuse sunrpc configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 raid10 raid456 libcrc32c crc32c_generic async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 multipath linear md_mod xen_pciback hid_generic nouveau usbhid hid sd_mod t10_pi crc_t10dif crct10dif_generic video mxm_wmi i2c_algo_bit drm_kms_helper cec ahci xhci_pci libahci ttm xhci_hcd crct10dif_pclmul crct10dif_common drm libata crc32c_intel scsi_mod usbcore usb_common wmi evdev gpio_amdpt gpio_generic button CPU: 0 PID: 2205 Comm: kworker/0:3 Not tainted 5.10.0-21-amd64 #1 Debian 5.10.162-1 Hardware name: Micro-Star International Co., Ltd. MS-7A34/B350 PC MATE(MS-7A34), BIOS A.E0 05/02/2018 Workqueue: events nouveau_cli_work [nouveau] RIP: e030:nvif_vmm_put+0x6e/0x80 [nouveau] Code: 00 00 48 89 e2 be 02 00 00 00 48 c7 04 24 00 00 00 00 48 89 44 24 08 e8 b0 e2 ff ff 85 c0 75 0a 48 c7 43 08 00 00 00 00 eb b3 <0f> 0b eb f2 e8 e9 19 4d c1 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 RSP: e02b:c90043187de0 EFLAGS: 00010282 RAX: fffe RBX: c90043187e08 RCX: RDX: RSI: c90043187d50 RDI: c90043187df0 RBP: 88801066e7c0 R08: fffe R09: R10: 0030 R11: 0018 R12: 8880085262a0 R13: dead0100 R14: 888008526540 R15: 888008526430 FS: () GS:88808000() knlGS: CS: e030 DS: ES: CR0: 80050033 CR2: 55f047765200 CR3: 0000084c2000 CR4: 00050660 Call Trace: nouveau_vma_del+0x7c/0xc0 [nouveau] nouveau_gem_object_delete_work+0x36/0x60 [nouveau] nouveau_cli_work+0xcc/0x120 [nouveau] process_one_work+0x1b6/0x350 worker_thread+0x53/0x3e0 ? process_one_work+0x350/0x350 kthread+0x11b/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x22/0x30 ---[ end trace 08a2448b87ab436b ]---
