Re: upgrade Debian-12 : Xorg noyau 6.1.0-13 ne fonctionne pas : résolu
On Friday 03 November 2023 08:35:58 Sébastien NOBILI wrote: > Le 2023-11-02 18:58, ajh-valmer a écrit : > > J'aurais préféré installer le driver proprio nvidia, > > mais il n'apparaît plus, dans leur base. > C'est bien le driver propriétaire nvidia que tu viens > d'installer, > Si tu regardes bien, c'est dans la section non-free : > https://packages.debian.org/bookworm/nvidia-tesla-470-driver D'accord, c'est pour ça que le driver fonctionne bien. Merci.
Re: upgrade Debian-12 : Xorg noyau 6.1.0-13 ne fonctionne pas : résolu
Bonjour, Le 2023-11-02 18:58, ajh-valmer a écrit : J'aurais préféré installer le driver proprio nvidia, mais il n'apparaît plus, dans leur base. C'est bien le driver propriétaire nvidia que tu viens d'installer 😉 Si tu regardes bien, c'est dans la section non-free : https://packages.debian.org/bookworm/nvidia-tesla-470-driver Sébastien
Re: upgrade Debian-12 : Xorg noyau 6.1.0-13 ne fonctionne pas : résolu
On Thursday 02 November 2023 19:54:58 Basile Starynkevitch wrote: > Dans certains cas, le pilote libre nouveau pourrait remplacer le pilote > propriétaire Nvidia. > https://nouveau.freedesktop.org/ J'avais tenté le pilote libre "nouveau" quand je croyais que celui de "Nvidia GeForce GT 710" n'était plus compatible avec un noyau récent : j'ai pas réussi. Fort heureusement, le pilote "nvidia-tesla-470-driver" le remplace très bien, sauvé !
Re: upgrade Debian-12 : Xorg noyau 6.1.0-13 ne fonctionne pas : résolu
On 11/2/23 18:58, ajh-valmer wrote: Merci à ceux qui m'ont aidé. Résolu en installant les paquets "nvidia-tesla-470" depuis ceux de Debian. J'aurais préféré installer le driver proprio nvidia, mais il n'apparaît plus, dans leur base. Allez bon pas grave, ça marche aussi bien. Bonne soirée. On Thursday 02 November 2023 17:09:23 ajh-valmer wrote: On Thursday 02 November 2023 15:38:07 Sébastien NOBILI wrote: C'est plutôt nvidia-tesla-470-driver qu'il faudrait installer. Probablement car le module est dispo pour l'une des versions du noyau mais pas l'autre : find /lib/modules/6.1.0-10-amd64 -name nvidia.ko find /lib/modules/6.1.0-13-amd64 -name nvidia. le module "nvidia-tesla-470-driver" est installé dans le noyau 6.1.0-10-amd64, et sans doute pas du tout dans le noyau "6.1.0-13-amd64" : find /lib/modules/6.1.0-10-amd64 -name nvidia.ko : installé find /lib/modules/6.1.0-13-amd64 -name nvidia.ko : pas installé Dans certains cas, le pilote libre nouveau pourrait remplacer le pilote propriétaire Nvidia. https://nouveau.freedesktop.org/ librement PS. Pour ma part, je cherche du soutien (des contributeurs, un consortium HorizonEurope?) pour le moteur d'inférence RefPerSys. Voir des idées sur http://refpersys.org/ et du code libre (GPLv3+) sur https://github.com/RefPerSys/RefPerSys/ -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: upgrade Debian-12 : Xorg noyau 6.1.0-13 ne fonctionne pas : résolu
Merci à ceux qui m'ont aidé. Résolu en installant les paquets "nvidia-tesla-470" depuis ceux de Debian. J'aurais préféré installer le driver proprio nvidia, mais il n'apparaît plus, dans leur base. Allez bon pas grave, ça marche aussi bien. Bonne soirée. On Thursday 02 November 2023 17:09:23 ajh-valmer wrote: > On Thursday 02 November 2023 15:38:07 Sébastien NOBILI wrote: > > C'est plutôt nvidia-tesla-470-driver qu'il faudrait installer. > > Probablement car le module est dispo pour l'une des versions du noyau > > mais pas l'autre : > > find /lib/modules/6.1.0-10-amd64 -name nvidia.ko > > find /lib/modules/6.1.0-13-amd64 -name nvidia. > le module "nvidia-tesla-470-driver" est installé dans le noyau > 6.1.0-10-amd64, > et sans doute pas du tout dans le noyau "6.1.0-13-amd64" : > find /lib/modules/6.1.0-10-amd64 -name nvidia.ko : installé > find /lib/modules/6.1.0-13-amd64 -name nvidia.ko : pas installé
Re: upgrade Debian-12 : Xorg noyau 6.1.0-13 ne fonctionne pas
On Thursday 02 November 2023 15:38:07 Sébastien NOBILI wrote: > C'est plutôt nvidia-tesla-470-driver qu'il faudrait installer. > Probablement car le module est dispo pour l'une des versions du noyau > mais pas l'autre : > find /lib/modules/6.1.0-10-amd64 -name nvidia.ko > find /lib/modules/6.1.0-13-amd64 -name nvidia.ko Ok, le module "nvidia-tesla-470-driver" est installé dans le noyau 6.1.0-10-amd64, et sans doute pas du tout dans le noyau "6.1.0-13-amd64" : find /lib/modules/6.1.0-10-amd64 -name nvidia.ko : installé find /lib/modules/6.1.0-13-amd64 -name nvidia.ko : pas installé
Re: upgrade Debian-12 : Xorg ne fonctionne plus
Le 2023-11-02 15:05, ajh-valmer a écrit : J'ai bien tapé cette commande avec le noyau 6.1.0-10-amd64 (Xorg fonctionnel) : dpkg-query: package 'nvidia-tesla-470-kernel-dkms' is not installed and no information is available. Avant d'installer le package 'nvidia-tesla-470-kernel-dkms', C'est plutôt nvidia-tesla-470-driver qu'il faudrait installer. comment se fait-il que Xorg marche très bien alors que le package n'est pas installé ? Probablement car le module est dispo pour l'une des vesions du noyau mais pas l'autre : find /lib/modules/6.1.0-10-amd64 -name nvidia.ko find /lib/modules/6.1.0-13-amd64 -name nvidia.ko Sébastien
Re: upgrade Debian-12 : Xorg ne fonctionne plus
> Le 2023-11-02 12:35, ajh-valmer a écrit : > > J'ai upgradé ma Debian 12, dans le /boot, je vois 2 noyaux : > > 6.1.0-10-amd64 et 6.1.0-13-amd64 > > Si je boote avec le noyau 6.1.0-13-amd64, > > Xorg ne fonctionne plus, j'aboutis à un mode console. > > Si noyau 6.1.0-10-amd64, Xorg fonctionne très bien. On Thursday 02 November 2023 13:13:40 Sébastien NOBILI wrote: > C'est donc deux versions identiques, la seconde étant une version > corrective de la première. > J'imagine que le module noyau n'a pas été correctement recompilé > à la mise à jour. Tu pourrais essayer cette commande : > dpkg-reconfigure nvidia-tesla-470-kernel-dkms > Tu devrais voir passer des messages qui indiquent que le module est > compilé pour ta version du noyau. > Ensuite, reboot et ça pourrait aller mieux. Merci. J'ai bien tapé cette commande avec le noyau 6.1.0-10-amd64 (Xorg fonctionnel) : dpkg-query: package 'nvidia-tesla-470-kernel-dkms' is not installed and no information is available. Avant d'installer le package 'nvidia-tesla-470-kernel-dkms', comment se fait-il que Xorg marche très bien alors que le package n'est pas installé ? @+
Re: upgrade Debian-12 : Xorg ne fonctionne plus
Le 2023-11-02 14:21, Michel Verdier a écrit : Il faut aussi les headers de la bonne version pour que dkms compile non ? dpkg -l linux-headers\* En effet, mais c'est une dépendance de dkms [1], lui-même étant une dépendance de nvidia-tesla-470-kernel-dkms [2]. Ils devraient donc être installés, sauf gros problème d'intégrité du gestionnaire de paquets. Sébastien 1: https://packages.debian.org/bookworm/dkms 2: https://packages.debian.org/bookworm/nvidia-tesla-470-kernel-dkms
Re: upgrade Debian-12 : Xorg ne fonctionne plus
Le 2 novembre 2023 Sébastien NOBILI a écrit : > J'imagine que le module noyau n'a pas été correctement recompilé > à la mise à jour. > Tu pourrais essayer cette commande : > > dpkg-reconfigure nvidia-tesla-470-kernel-dkms > > Tu devrais voir passer des messages qui indiquent que le module est > compilé pour ta version du noyau. Il faut aussi les headers de la bonne version pour que dkms compile non ? dpkg -l linux-headers\*
Re: upgrade Debian-12 : Xorg ne fonctionne plus
Bonjour, Le 2023-11-02 12:35, ajh-valmer a écrit : J'ai upgradé ma Debian 12, dans le /boot, je vois 2 noyaux : 6.1.0-10-amd64 et 6.1.0-13-amd64 C'est donc deux versions identiques, la seconde étant une version corrective de la première. Si je boote avec le noyau 6.1.0-13-amd64, Xorg ne fonctionne plus, j'aboutis à un mode console. J'imagine que le module noyau n'a pas été correctement recompilé à la mise à jour. Tu pourrais essayer cette commande : dpkg-reconfigure nvidia-tesla-470-kernel-dkms Tu devrais voir passer des messages qui indiquent que le module est compilé pour ta version du noyau. Ensuite, reboot et ça pourrait aller mieux. Sébastien
upgrade Debian-12 : Xorg ne fonctionne plus
Bonjour, J'ai upgradé ma Debian 12, dans le /boot, je vois 2 noyaux : 6.1.0-10-amd64 et 6.1.0-13-amd64 Si je boote avec le noyau 6.1.0-10-amd64 le système graphique Xorg fonctionne très bien avec cette carte : nvidia-detect GK208B [GeForce GT 710] Your card is supported by the Tesla 470 drivers series. It is recommended to install the "nvidia-tesla-470-driver" package, ce qui est bien le cas. Si je boote avec le noyau 6.1.0-13-amd64, Xorg ne fonctionne plus, j'aboutis à un mode console. Comment se fait-il ? Avez vous une idée ? Bonne journée. André Valmer
Re: SID Xorg Erreur Segmentation
Bonjour, J'ai finalement installé les driver nvidia, un simple : apt-get install nvidia-driver a résolu le problème, le driver s'installe très simplement. Je suppose que mon problème est dans nouveau ou mesa, peut être libglamoregl.so. moralité ; si vous faites des bêtises avec Sid pensez à avoir une partition avec une testing ou un ubuntu au cas ou! et zless et zmore c'est bien! Merci de m'avoir proposé des solutions! On Sun, Jan 8, 2023 at 8:51 PM Basile Starynkevitch < bas...@starynkevitch.net> wrote: > > On 08/01/2023 19:49, Orion wrote: > > merci pour vos réponses! > je pense que didier gaumet qui a la meilleure piste, ça peut venir de > mesa, > j'ai cherché sur apt-list-bug mais c'est pas concluant, > apparemment apt ne garde pas mes réponses suite à ses mises en garde. > lspci > 00:00.0 Host bridge: Intel Corporation 8th Gen Core Processor Host > Bridge/DRAM Registers (rev 07) > 00:01.0 PCI bridge: Intel Corporation 6th-10th Gen Core Processor PCIe > Controller (x16) (rev 07) > 00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-S GT2 [UHD > Graphics 630] > 00:14.0 USB controller: Intel Corporation 200 Series/Z370 Chipset Family > USB 3.0 xHCI Controller > 00:16.0 Communication controller: Intel Corporation 200 Series PCH CSME > HECI #1 > 00:17.0 SATA controller: Intel Corporation 200 Series PCH SATA controller > [AHCI mode] > 00:1b.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port > #17 (rev f0) > 00:1c.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port > #1 (rev f0) > 00:1c.3 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port > #4 (rev f0) > 00:1d.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port > #9 (rev f0) > 00:1d.4 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port > #13 (rev f0) > 00:1f.0 ISA bridge: Intel Corporation Z370 Chipset LPC/eSPI Controller > 00:1f.2 Memory controller: Intel Corporation 200 Series/Z370 Chipset > Family Power Management Controller > 00:1f.3 Audio device: Intel Corporation 200 Series PCH HD Audio > 00:1f.4 SMBus: Intel Corporation 200 Series/Z370 Chipset Family SMBus > Controller > 01:00.0 VGA compatible controller: *NVIDIA Corporation TU106 [GeForce RTX > 2070 Rev. A]* (rev a1) > 01:00.1 Audio device: NVIDIA Corporation TU106 High Definition Audio > Controller (rev a1) > 01:00.2 USB controller: NVIDIA Corporation TU106 USB 3.1 Host Controller > (rev a1) > 01:00.3 Serial bus controller: NVIDIA Corporation TU106 USB Type-C UCSI > Controller (rev a1) > 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) > > > > Donc une carte NVIDIA récente: je suggère alors soit d'utiliser Nouveau > (pour les libristes convaincus) via > > aptitude install libdrm-nouveau2 nouveau-firmware > xserver-xorg-video-nouveau > > soit d'accepter le compromis de télécharger puis d'installer un pilote > NVIDIA propriétaire: https://www.nvidia.com/fr-fr/drivers/unix/ donc en > janvier 2023 > https://www.nvidia.fr/content/DriverDownloads/confirmation.php?url=/XFree86/Linux-x86_64/525.78.01/NVIDIA-Linux-x86_64-525.78.01.run&lang=fr&type=TITAN > > et il faudra bien sûr rebooter, et préalablement avoir installer le code > source du noyau (nécessaire à Nvidia, si j'ai bonne mémoire) ou au moins > les paquets linux-headers > > -- > Basile Starynkevitch > > (only mine opinions / les opinions sont miennes uniquement) > 92340 Bourg-la-Reine, France > web page: starynkevitch.net/Basile/ > >
Re: Plantages Xorg sur Bookworm
On 17/01/2023 15:26, Thierry wrote: Bonjour J'ai toujours un comportement étrange de la session graphique sur Bookworm. Constat: aléatoirement, clavier et souris partent en vrille. Par exemple, je peux bouger la souris, mais le click ne donne rien. Au clavier certaines touches sont inopérantes, d'autres affichent autre chose (ex: le t affiche un :). Pour débloquer, je lance une session non graphique (Ctrl Alt F1) et je reviens (Ctrl Alt F7) et çà repart.. Dans le log Xorg, je vois les lignes suivantes: 19411.561] (II) event2 - Power Button: device removed [ 19411.710] (II) event3 - Video Bus: device removed [ 19411.755] (II) event1 - Power Button: device removed [ 19411.770] (II) event4 - MOSART Semi. 2.4G Wireless Mouse: device removed [ 19411.803] (II) event0 - AT Translated Set 2 keyboard: device removed [ 19412.252] (II) AIGLX: Suspending AIGLX clients for VT switch [ 19414.029] (II) AIGLX: Resuming AIGLX clients after VT switch Une idée de la cause du problème? Non, mais peut-être que l'utilitaire xev (probablement dans le paquet /x11-utils/) pourrait vous aider à le comprendre. Bonne année à tous. PS. Je cherche des gens intéressés par le projet logiciel libre /RefPerSys/ en http://refpersys.org/ . -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Plantages Xorg sur Bookworm
Bonjour J'ai toujours un comportement étrange de la session graphique sur Bookworm. Constat: aléatoirement, clavier et souris partent en vrille. Par exemple, je peux bouger la souris, mais le click ne donne rien. Au clavier certaines touches sont inopérantes, d'autres affichent autre chose (ex: le t affiche un :). Pour débloquer, je lance une session non graphique (Ctrl Alt F1) et je reviens (Ctrl Alt F7) et çà repart.. Dans le log Xorg, je vois les lignes suivantes: 19411.561] (II) event2 - Power Button: device removed [ 19411.710] (II) event3 - Video Bus: device removed [ 19411.755] (II) event1 - Power Button: device removed [ 19411.770] (II) event4 - MOSART Semi. 2.4G Wireless Mouse: device removed [ 19411.803] (II) event0 - AT Translated Set 2 keyboard: device removed [ 19412.252] (II) AIGLX: Suspending AIGLX clients for VT switch [ 19414.029] (II) AIGLX: Resuming AIGLX clients after VT switch Une idée de la cause du problème? Pas bloquant, mais pénible à la longue. Merci
Re: SID Xorg Erreur Segmentation
On 08/01/2023 19:49, Orion wrote: merci pour vos réponses! je pense que didier gaumet qui a la meilleure piste, ça peut venir de mesa, j'ai cherché sur apt-list-bug mais c'est pas concluant, apparemment apt ne garde pas mes réponses suite à ses mises en garde. lspci 00:00.0 Host bridge: Intel Corporation 8th Gen Core Processor Host Bridge/DRAM Registers (rev 07) 00:01.0 PCI bridge: Intel Corporation 6th-10th Gen Core Processor PCIe Controller (x16) (rev 07) 00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630] 00:14.0 USB controller: Intel Corporation 200 Series/Z370 Chipset Family USB 3.0 xHCI Controller 00:16.0 Communication controller: Intel Corporation 200 Series PCH CSME HECI #1 00:17.0 SATA controller: Intel Corporation 200 Series PCH SATA controller [AHCI mode] 00:1b.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #17 (rev f0) 00:1c.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #1 (rev f0) 00:1c.3 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #4 (rev f0) 00:1d.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #9 (rev f0) 00:1d.4 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #13 (rev f0) 00:1f.0 ISA bridge: Intel Corporation Z370 Chipset LPC/eSPI Controller 00:1f.2 Memory controller: Intel Corporation 200 Series/Z370 Chipset Family Power Management Controller 00:1f.3 Audio device: Intel Corporation 200 Series PCH HD Audio 00:1f.4 SMBus: Intel Corporation 200 Series/Z370 Chipset Family SMBus Controller 01:00.0 VGA compatible controller: *NVIDIA Corporation TU106 [GeForce RTX 2070 Rev. A]* (rev a1) 01:00.1 Audio device: NVIDIA Corporation TU106 High Definition Audio Controller (rev a1) 01:00.2 USB controller: NVIDIA Corporation TU106 USB 3.1 Host Controller (rev a1) 01:00.3 Serial bus controller: NVIDIA Corporation TU106 USB Type-C UCSI Controller (rev a1) 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) Donc une carte NVIDIA récente: je suggère alors soit d'utiliser Nouveau (pour les libristes convaincus) via aptitude install libdrm-nouveau2 nouveau-firmware xserver-xorg-video-nouveau soit d'accepter le compromis de télécharger puis d'installer un pilote NVIDIA propriétaire: https://www.nvidia.com/fr-fr/drivers/unix/ donc en janvier 2023 https://www.nvidia.fr/content/DriverDownloads/confirmation.php?url=/XFree86/Linux-x86_64/525.78.01/NVIDIA-Linux-x86_64-525.78.01.run&lang=fr&type=TITAN <https://www.nvidia.fr/content/DriverDownloads/confirmation.php?url=/XFree86/Linux-x86_64/525.78.01/NVIDIA-Linux-x86_64-525.78.01.run&lang=fr&type=TITAN> et il faudra bien sûr rebooter, et préalablement avoir installer le code source du noyau (nécessaire à Nvidia, si j'ai bonne mémoire) ou au moins les paquets linux-headers -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: SID Xorg Erreur Segmentation
Am 08/01/2023 um 19:49 schrieb Orion: merci pour vos réponses! J'ai un peu de mal à m'en souvenir, mais il me semble avoir eu le même problème sous unstable il y a qq semaines, et la solution était de revenir à une version antérieure de xorg. Mais le problème a peut-être était résolu depuis, au moins sous unstable. Il me semble qu'il y avait un report de bug, ça doit se trouver facilement. J'ai ~$ apt-cache policy xserver-xorg xserver-xorg: Installé: 1:7.7+23 Candidat: 1:7.7+23 Versionstabelle: *** 1:7.7+23 500 500 http://ftp.halifax.rwth-aachen.de/debian unstable/main amd64 Packages 100 /var/lib/dpkg/status bye Klaus
Re: SID Xorg Erreur Segmentation
merci pour vos réponses! je pense que didier gaumet qui a la meilleure piste, ça peut venir de mesa, j'ai cherché sur apt-list-bug mais c'est pas concluant, apparemment apt ne garde pas mes réponses suite à ses mises en garde. mon xorg log : X.Org X Server 1.21.1.6 X Protocol Version 11, Revision 0 [79.378] Current Operating System: Linux debian 6.0.0-6-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.12-1 (2022-12-09) x86_64 [79.378] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.0.0-6-amd64 root=UUID=1083d7f2-5605-4c39-b74e-987011602c8e ro single [ 79.380] xorg-server 2:21.1.6-1 (https://www.debian.org/support) [79.381] Current version of pixman: 0.42.2 [79.384] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [79.384] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [79.389] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Jan 8 16:25:51 2023 [79.390] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [79.390] (==) No Layout section. Using the first Screen section. [79.390] (==) No screen section available. Using defaults. [79.390] (**) |-->Screen "Default Screen Section" (0) [79.390] (**) | |-->Monitor "" [79.390] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [79.390] (==) Automatically adding devices [79.390] (==) Automatically enabling devices [79.390] (==) Automatically adding GPU devices [79.390] (==) Automatically binding GPU devices [79.390] (==) Max clients allowed: 256, resource mask: 0x1f [79.390] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [79.390] Entry deleted from font path. [79.390] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [79.390] (==) ModulePath set to "/usr/lib/xorg/modules" [79.390] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [79.390] (II) Loader magic: 0x556d58f82f00 [79.390] (II) Module ABI versions: [79.390] X.Org ANSI C Emulation: 0.4 [79.390] X.Org Video Driver: 25.2 [79.390] X.Org XInput driver : 24.4 [79.390] X.Org Server Extension : 10.0 [79.390] (EE) dbus-core: error connecting to system bus: org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory) [79.390] (--) using VT number 2 [79.390] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [79.391] (II) xfree86: Adding drm device (/dev/dri/card0) [79.391] (II) Platform probe for /sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0 [79.392] (II) xfree86: Adding drm device (/dev/dri/card1) [79.392] (II) Platform probe for /sys/devices/pci:00/:00:02.0/drm/card1 [79.399] (--) PCI:*(0@0:2:0) 8086:3e92:1043:8694 rev 0, Mem @ 0xf500/16777216, 0xd000/268435456, I/O @ 0xf000/64, BIOS @ 0x/131072 [79.399] (--) PCI: (1@0:0:0) 10de:1f07:1043:866d rev 161, Mem @ 0xf600/16777216, 0xe000/268435456, 0xf000/33554432, I/O @ 0xe000/128, BIOS @ 0x????/524288 [79.399] (II) LoadModule: "glx" [79.399] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [79.400] (II) Module glx: vendor="X.Org Foundation" [79.400] compiled for 1.21.1.6, module version = 1.0.0 [79.400] ABI class: X.Org Server Extension, version 10.0 [79.466] (==) Matched modesetting as autoconfigured driver 0 [79.466] (==) Matched fbdev as autoconfigured driver 1 [79.466] (==) Matched vesa as autoconfigured driver 2 [79.466] (==) Assigned the driver to the xf86ConfigLayout [79.466] (II) LoadModule: "modesetting" [79.466] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [79.466] (II) Module modesetting: vendor="X.Org Foundation" [79.466]* compiled for 1.21.1.6, module version = 1.21.1* [79.466] Module class: X.Org Video Driver [79.466] *ABI class: X.Org Video Driver, version 25.2* [79.466] (II) LoadModule: "fbdev" [79.467] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [79.467] (II) Module fbdev: vendor="X.Org Foundation" [79.467] compiled for 1.21.1.3, module version = 0.5.0 [79.467] Module class: X.Org Video Driver [79.467] ABI class: X.Org Video Driver, version 25.2 [79.467] (II) LoadModule: "vesa" [79.467] (II) Loading /u
Re: SID Xorg Erreur Segmentation
Le 08/01/2023 à 11:47, Orion a écrit : Bonjour, Suite à une mise à jour autour du 31/12, Xorg ne démarre plus, je me souviens d'un message d'alerte d'apt list bug lors de la maj parlant d'un risque de segmentation error mais je me pensais sous Wayland et non concerné. Quelqu'un a t il peut être vu le message et a un lien vers une solution? Merci - Solution? Je ne suis as sûr, à part attendre que le bug soit corrigé dans Sid ou réinstaller une version antérieure à condition de ne pas avoir purgé (tu peux aussi trouver des versions particulières des exécutables sur https://snapshot.debian.org/ ) - le dépistage peut probablement s'effectuer en cherchant (mots clé xorg et xserver) les paquets xorg installés sur ton système et en cherchant pour chacun d'eux les bugs sur le site https://www.debian.org/Bugs/ . Tu devrais pouvoir obtenir en local le même résultat par la commande apt-listbugs list paquet_à_vérifier.
Re: SID Xorg Erreur Segmentation
On 08/01/2023 11:47, Orion wrote: Bonjour, Suite à une mise à jour autour du 31/12, Xorg ne démarre plus, je me souviens d'un message d'alerte d'apt list bug lors de la maj parlant d'un risque de segmentation error mais je me pensais sous Wayland et non concerné. Quelqu'un a t il peut être vu le message et a un lien vers une solution? Sans aucune garantie que ça marche (car Xorg comme Wayland dépend du matériel, c'est différent avec un contrôleur graphique NVIDIA et avec une carte graphique AMD) je vous invite à faire (sous root, en console - il faut peut être booter en mode rescue) les commandes suivantes et à en poster sur debian-user-french les effets. mise à jour des paquets et installation de xfce4 aptitude update aptitude upgrade aptitude install xfce4-session redemarrage reboot interrogation du matériel lspci lscpu tentative de redemarrage du serveur Xorg startx /usr/bin/xfce4-session regarder avec less /var/log/Xorg.0.log les messages d'erreurs puis grep -ni5 error /var/log/Xorg.0.log Pour ma part, je vous souhaite une bonne année 2023 et cherche des partenaires intéressés par /RefPerSys/ en http://refpersys.org/ Bonne fin de weekend -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
SID Xorg Erreur Segmentation
Bonjour, Suite à une mise à jour autour du 31/12, Xorg ne démarre plus, je me souviens d'un message d'alerte d'apt list bug lors de la maj parlant d'un risque de segmentation error mais je me pensais sous Wayland et non concerné. Quelqu'un a t il peut être vu le message et a un lien vers une solution? Merci
Re: Plantages Xorg (i915, context reset due to GPU hang)
Daniel Caillibaud a écrit : > Le 02/07/21 à 10:18, BERTRAND Joël a écrit : >> Dans le BIOS, tu as un paramètre pour affecter de la RAM à la carte >> graphique. > >> Il doit y avoir un paramètre quelque part. Je n'ai encore jamais vu de >> carte-mère sans que cela soit réglable > > Ben, j'ai vraiment fait toutes les pages de paramétrage du bios et rien vu > là-dessus (c'est > une machine d'entrée de gamme qui ne peut pas recevoir de carte graphique > dédiée, ceci > explique peut-être cela). > > C'est peut-être une "amélioration" sur cette carte (ou le bios) qui > allouerait d'office au GPU > la RAM nécessaire à gérer sa résolution max (vu qu'on peut ajouter des écrans > à chaud il vaut > mieux que le GPU ait la RAM nécessaire), j'en sais trop rien… > > Il s'agit d'un cpu i5 de 10e génération, et vu que 32, 64 ou 128Mo ne > changent pas grand chose > quand tu as plusieurs Go de RAM (de 4 à 16 sur cette machine), ce bios dell > fait peut-être > cette allocation au max de manière systématique, ce serait pas idiot. Dell ? Fallais le dire plus tôt ;-) Je n'ai jamais eu que des problèmes avec leurs machines. JKB
Re: Plantages Xorg (i915, context reset due to GPU hang)
Le 02/07/21 à 10:18, BERTRAND Joël a écrit : > Dans le BIOS, tu as un paramètre pour affecter de la RAM à la carte > graphique. > Il doit y avoir un paramètre quelque part. Je n'ai encore jamais vu de > carte-mère sans que cela soit réglable Ben, j'ai vraiment fait toutes les pages de paramétrage du bios et rien vu là-dessus (c'est une machine d'entrée de gamme qui ne peut pas recevoir de carte graphique dédiée, ceci explique peut-être cela). C'est peut-être une "amélioration" sur cette carte (ou le bios) qui allouerait d'office au GPU la RAM nécessaire à gérer sa résolution max (vu qu'on peut ajouter des écrans à chaud il vaut mieux que le GPU ait la RAM nécessaire), j'en sais trop rien… Il s'agit d'un cpu i5 de 10e génération, et vu que 32, 64 ou 128Mo ne changent pas grand chose quand tu as plusieurs Go de RAM (de 4 à 16 sur cette machine), ce bios dell fait peut-être cette allocation au max de manière systématique, ce serait pas idiot. La commande `free -b` m'annonce 16159100 bytes au total, ce qui fait 15.41Gio (je suppose qu'une barette annoncée pour 16G fait 16Gio, donc ici y'aurait ~600Mio qui auraient été consommé par qqun) En tout cas merci pour tes explications. -- Daniel Le génie, c'est 1% d'inspiration et 99% de transpiration. Edison
Re: Plantages Xorg (i915, context reset due to GPU hang)
Daniel Caillibaud a écrit : > Le 01/07/21 à 21:03, BERTRAND Joël a écrit : >> Je ne me souviens pas, mais quelle est la taille de la mémoire >> graphique sur la machine en question ? > > Aucune idée… > > Comment je peux voir ça ? Dans le BIOS, tu as un paramètre pour affecter de la RAM à la carte graphique. J'ai fait la bêtise sur un poste de bureautique avec un i5 de limiter cette taille à 32 ou 64 Mo (je ne sais plus) et j'ai observé tout un tas de plantages divers et variés que ce soit sous Linux ou sous FreeBSD que, naturellement, personne n'arrivait à reproduire. Les applications qt5 plantaient immédiatement, les autres, beaucoup plus aléatoirement en fonction des allocations mémoires demandées par les bibliothèques graphiques (OpenGL est connue pour bufferiser côté client et ne balancer qu'une seule requête sans vérification côté serveur quitte à dépasser la mémoire de la carte graphique ou sa capacité d'adressage. En CAO, ça peut être rigolo, un outil comme KiCAD pouvant morceler ses requêtes sans empêcher OpenGL de balancer une requête ne tenant pas sur l'espace d'adressage du GPU qui est de 32 bits pour un i7-4490 !... Si ça, ce n'est pas un bug, je ne sais pas ce que c'est !). J'ai subi cela jusqu'au moment où j'ai tenté l'augmentation à 128 Mo et là, miracle, tout fonctionnait. >> Ça vaut le coup d'augmenter la taille pour voir si cela change quelque chose. > > J'ai fouillé tous les paramètres du bios en mode avancé mais rien trouvé qui > me permette de > choisir ça. > > Vu que c'est le chipset vidéo embarqué sur le CPU qui gère ça, il se sert pas > tout seul dans la > RAM en fonction de ses besoins ? Il doit y avoir un paramètre quelque part. Je n'ai encore jamais vu de carte-mère sans que cela soit réglable (pour les générations jusqu'à la 7e incluse, après cette aventure et comme j'ai besoin pour la CAO de carte graphique qui dépote avec un adressage d'au moins 8 Go, j'ai pris des CPU sans GPU et je ne me suis plus préoccupé de la chose). Sinon, les sorties de X devraient te renseigner. Le GPU ne peut se servir lui-même dans la RAM. Il doit initialiser la mémoire au démarrage en mémoire utilisable par le système et RAM graphique (sinon, le noyau ne connaît pas la limite). En dehors de quelques systèmes bien spécialisés, il est impossible de modifier la quantité de mémoire d'un système dynamiquement. Bien cordialement, JKB
Re: Plantages Xorg (i915, context reset due to GPU hang)
Le 01/07/21 à 21:03, BERTRAND Joël a écrit : > Je ne me souviens pas, mais quelle est la taille de la mémoire > graphique sur la machine en question ? Aucune idée… Comment je peux voir ça ? > Ça vaut le coup d'augmenter la taille pour voir si cela change quelque chose. J'ai fouillé tous les paramètres du bios en mode avancé mais rien trouvé qui me permette de choisir ça. Vu que c'est le chipset vidéo embarqué sur le CPU qui gère ça, il se sert pas tout seul dans la RAM en fonction de ses besoins ? C'est ce processeur https://ark.intel.com/content/www/us/en/ark/products/196603/intel-core-i5-1035g1-processor-6m-cache-up-to-3-60-ghz.html Dans ses specs (pdf "10th Gen Intel® Core™ Processor Families Datasheet, Volume 2 of 2" récupéré sur cette page) on peut lire ce qui suit (qui me cause pas vraiment) 2.9 Graphics Memory Address Ranges The integrated memory controller can be programmed to direct memory accesses to the Processor Graphics when addresses are within any of the ranges specified using registers in MCH Device 2 configuration space. • The Graphics Memory Aperture Base Register (GMADR) is used to access graphics memory allocated using the graphics translation table. • The Graphics Translation Table Base Register (GTTADR) is used to access the translation table and graphics control registers. This is part of the GTTMMADR register. These ranges can reside above the Top-of-Low-DRAM and below High BIOS and APIC address ranges. They should reside above the top of memory (TOLUD) and below 4 GB so they do not take any physical DRAM memory space. Alternatively, these ranges can reside above 4 GB, similar to other BARs that are larger than 32 bits in size. GMADR is a Prefetchable range in order to apply USWC attribute (from the processor point of view) to that range. The USWC attribute is used by the processor for write combining. 2.9.1 IOBAR Mapped Access to Device 2 MMIO Space Device 2, Processor Graphics, contains an IOBAR register. If Device 2 is enabled, Processor Graphics registers or the GTT table can be accessed using this IOBAR. The IOBAR is composed of an index register and a data register. MMIO_Index: MMIO_INDEX is a 32-bit register. A 32-bit (all bytes enabled) I/O write to this port loads the offset of the MMIO register or offset into the GTT that needs to be accessed. An I/O Read returns the current value of this register. I/O read/write accesses less than 32 bits in size (all bytes enabled) will not target this register. MMIO_Data: MMIO_DATA is a 32-bit register. A 32-bit (all bytes enabled) I/O write to this port is re-directed to the MMIO register pointed to by the MMIO-index register. An I/O read to this port is re-directed to the MMIO register pointed to by the MMIO-index register. I/O read/write accesses less than 32 bits in size (all bytes enabled) will not target this register. The result of accesses through IOBAR can be: • Accesses directed to the GTT table. (that is, route to DRAM) • Accesses to Processor Graphics registers with the device. • Accesses to Processor Graphics display registers now located within the PCH. (that is, route to DMI). Note: GTT table space writes (GTTADR) are supported through this mapping mechanism. This mechanism to access Processor Graphics MMIO registers should NOT be used to access VGA I/O registers that are mapped through the MMIO space. VGA registers should be accessed directly through the dedicated VGA I/O ports. 2.9.2 Trusted Graphics Ranges Trusted graphics ranges are NOT supported. -- Daniel Les Etats-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation. Albert Einstein.
Re: Plantages Xorg (i915, context reset due to GPU hang)
Le 01/07/21 à 20:30, Étienne Mollier a écrit : > Je n'ai jamais eu l'occasion d'utiliser slack, donc peut-être > que mon idée n'aura pas beaucoup de sens, mais est-ce que slack > propose de désactiver l'accélération graphique ? Peut-être que > désactiver ce paramètre aiderait à la stabilité de la machine ? Effectivement, cette case existe et était cochée, mais je ne me souviens pas exactement quand je l'ai fait, c'est pas très vieux. Mais l'accélération matérielle de slack pourrait planter le module i915 alors qu'il n'y a pas de fenêtre de l'appli ouverte ? (la plupart du temps il tourne en arrière plan, en tout cas dans la très grande majorité de mes plantages il n'y avait pas de fenêtre slack, même réduite, juste l'icone de slack dans la zone dont j'ai oublié le nom, à coté de l'heure/son/wifi/…) > J'ai téléchargé un .deb de slack-desktop 4.17.0[1] depuis le > site de slack.com Pfff, même ça je l'avais pas trouvé, j'avais installé via snapd n'ayant pas trouvé ce deb. J'ai désinstallé slack via snapd, désinstallé snapd (j'aime pas trop avoir un truc qui tourne dans le dos d'apt pour faire son boulot) et installé ce .deb. > et j'ai vu que le programme embarquait un > chrome-sandbox setuid, combiné à des bibliothèques OpenGL et > Vulkan tierces. D'où l'idée que, si ce programme exécute des > bibliothèques graphiques buguées en tant que root, alors > peut-être que ça expliquerait les crashes avec le pilote i915. Merci pour cette excellente piste ! Je le laisse tourner avec l'accélération matérielle désactivée, on verra… -- Daniel Il est très curieux de constater que dans l'armée, les statistiques le prouvent, la mortalité augmente bizarrement en temps de guerre. Alphonse Allais pgpUIlWwMeI23.pgp Description: Signature digitale OpenPGP
Re: Plantages Xorg (i915, context reset due to GPU hang)
Bonjour Daniel, Daniel Caillibaud, on 2021-07-01: > Le 16/06/21 à 13:13, Daniel Caillibaud a écrit : > > J'ai commencé par mettre les options > > intel_idle.max_cstate=1 i915.enable_dc=0 > > Ça n'a rien changé. > > J'ai ensuite désactivé dans le bios toutes les optimisation cpu (cstate, > speed state, turbo > boost), et je me suis retrouvé avec un gros veau (délais ×2 à ×6 suivant les > tâches) qui > plantait un peu moins mais plantait quand même. > > J'avais qq espoirs après là mise à jour du paquet intel-microcode de lundi, > encore raté… > > J'ai par ailleurs constaté que mon client slack-desktop était vraiment > goinfre en RAM, je l'ai > fermé, et depuis ça n'a pas planté… > > Ce n'est peut-être pas lui qui est directement en cause, mais la conjonction > d'opérations qui > menaient au plantage (et que j'ai pas identifié) semble ne plus se produire > depuis qu'il ne > tourne plus… > > (c'était un slack-deskop installé sous jessie depuis la source > deb https://packagecloud.io/slacktechnologies/slack/debian/ jessie main > que j'ai récemment réinstallé avec snap, j'avais des plantages avec les deux > versions) Je n'ai jamais eu l'occasion d'utiliser slack, donc peut-être que mon idée n'aura pas beaucoup de sens, mais est-ce que slack propose de désactiver l'accélération graphique ? Peut-être que désactiver ce paramètre aiderait à la stabilité de la machine ? J'ai téléchargé un .deb de slack-desktop 4.17.0[1] depuis le site de slack.com, et j'ai vu que le programme embarquait un chrome-sandbox setuid, combiné à des bibliothèques OpenGL et Vulkan tierces. D'où l'idée que, si ce programme exécute des bibliothèques graphiques buguées en tant que root, alors peut-être que ça expliquerait les crashes avec le pilote i915. Bonne soirée, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/0, please excuse my verbosity. Pour référence : [1] : https://downloads.slack-edge.com/linux_releases/slack-desktop-4.17.0-amd64.deb signature.asc Description: PGP signature
Re: Plantages Xorg (i915, context reset due to GPU hang)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Étienne Mollier a écrit : > Bonjour Daniel, > > Daniel Caillibaud, on 2021-07-01: >> Le 16/06/21 à 13:13, Daniel Caillibaud a >> écrit : >>> J'ai commencé par mettre les options intel_idle.max_cstate=1 >>> i915.enable_dc=0 >> >> Ça n'a rien changé. >> >> J'ai ensuite désactivé dans le bios toutes les optimisation cpu >> (cstate, speed state, turbo boost), et je me suis retrouvé avec >> un gros veau (délais ×2 à ×6 suivant les tâches) qui plantait un >> peu moins mais plantait quand même. >> >> J'avais qq espoirs après là mise à jour du paquet intel-microcode >> de lundi, encore raté… >> >> J'ai par ailleurs constaté que mon client slack-desktop était >> vraiment goinfre en RAM, je l'ai fermé, et depuis ça n'a pas >> planté… >> >> Ce n'est peut-être pas lui qui est directement en cause, mais la >> conjonction d'opérations qui menaient au plantage (et que j'ai >> pas identifié) semble ne plus se produire depuis qu'il ne tourne >> plus… >> >> (c'était un slack-deskop installé sous jessie depuis la source >> deb https://packagecloud.io/slacktechnologies/slack/debian/ >> jessie main que j'ai récemment réinstallé avec snap, j'avais des >> plantages avec les deux versions) > > Je n'ai jamais eu l'occasion d'utiliser slack, donc peut-être que > mon idée n'aura pas beaucoup de sens, mais est-ce que slack propose > de désactiver l'accélération graphique ? Peut-être que désactiver > ce paramètre aiderait à la stabilité de la machine ? > > J'ai téléchargé un .deb de slack-desktop 4.17.0[1] depuis le site > de slack.com, et j'ai vu que le programme embarquait un > chrome-sandbox setuid, combiné à des bibliothèques OpenGL et Vulkan > tierces. D'où l'idée que, si ce programme exécute des > bibliothèques graphiques buguées en tant que root, alors peut-être > que ça expliquerait les crashes avec le pilote i915. Bonsoir, En fait, toutes les bibliothèques d'accélération graphiques sont buggués parce qu'elles ne vérifient pas les allocations mémoire. La plupart du temps, ça termine par un segfault de l'application, mais ça peut aussi terminer beaucoup plus mal par un crash noyau. J'ai cherché un tel bug durant des années, bug lié à la taille de la mémoire graphiqu e. Je ne me souviens pas, mais quelle est la taille de la mémoire graphique sur la machine en question ? Ça vaut le coup d'augmenter la taille pour voir si cela change quelque chose. Bien cordialement, JKB -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEq4YCoAJMwLElZVYXOAfo0lKQ8+cFAmDeEWIACgkQOAfo0lKQ 8+eyQA/9GR5OXUPW+Ztbw3la+cOTTbGTUwLSVMSUGL0pWSAA2HP8AMLYD7Ac19bt iDjYfGCN7E781dBabL3L4UN2+GNmUhm8YU6gp5TpLCjYNyYHq2p+cvxO47zVSW+u YS7US4LubW6jwtxVC13Fpk5MvAJlzz0NdESWwjn1XdoSqS+6SCO2VV/zWtVNZB6q dfOjA67g8o86KOej5sQiEeTSXUoaKWiU39X8VhuA5TUQhc+M4VhxTZocT5LMil6l EY6WXlE97vyBDBFy3C84UYFXOiS3yRXVYB5+rxT0wogbvBseJYnhA9LmO3g62PRn IaWHu8LCzwIOURhkZdqIlNsMHY7pRo9+j7PGGk168cnH2I2FQfYNmuilNTzddlhu EaCbbDyeX0sE9r0+N0j9c+UOAW2F/YmknW8GVg1JpWHFAsN0PIMtkIiScj9whHrS x5ibL0CHr+MJcNZpNR8y0Qtq50kTLlB+w9k7oeAcZpZRMqrODJOPbs4EkchFEMte gLdG/oeaep3bqtThkawSPfRz7NCjgtdeysl4Mn6e0xfM39i8gmpxMe26GF1Mne3+ ivmgJnaxecQTP5SQS2Kh8NewCaCDL1DlvxZFuOpmvmfuEGl2TllLbhse7LVrh4QJ FZxsoM9nGB9g5zgllo5aTLCJqMwctkfeveK/oF4yfZ0B4LOFGm0= =2Nkb -END PGP SIGNATURE-
Re: Plantages Xorg (i915, context reset due to GPU hang)
Le 16/06/21 à 13:13, Daniel Caillibaud a écrit : > J'ai commencé par mettre les options > intel_idle.max_cstate=1 i915.enable_dc=0 Ça n'a rien changé. J'ai ensuite désactivé dans le bios toutes les optimisation cpu (cstate, speed state, turbo boost), et je me suis retrouvé avec un gros veau (délais ×2 à ×6 suivant les tâches) qui plantait un peu moins mais plantait quand même. J'avais qq espoirs après là mise à jour du paquet intel-microcode de lundi, encore raté… J'ai par ailleurs constaté que mon client slack-desktop était vraiment goinfre en RAM, je l'ai fermé, et depuis ça n'a pas planté… Ce n'est peut-être pas lui qui est directement en cause, mais la conjonction d'opérations qui menaient au plantage (et que j'ai pas identifié) semble ne plus se produire depuis qu'il ne tourne plus… (c'était un slack-deskop installé sous jessie depuis la source deb https://packagecloud.io/slacktechnologies/slack/debian/ jessie main que j'ai récemment réinstallé avec snap, j'avais des plantages avec les deux versions) -- Daniel Il n'est pas de vent favorable pour celui qui ne sait où il va. Sénèque
Re: Plantages Xorg (i915, context reset due to GPU hang)
Le 15/06/21 à 19:40, Étienne Mollier a écrit : > Argh, dommage, bon au moins, ça valait le coup d'essayer… Oui, merci pour la piste > […] > > /var/log/Xorg.0.log est vide > > Ça me surprend, en temps normal il y a toujours beaucoup de > verbiage dans les journaux d'Xorg. Il a été remis à zéro, > démarré en tant qu'utilisateur (~/.local/share/xorg/Xorg.0.log), > ou démarré sur un autre display (Xorg.1.log) ? (Simple > curiosité, pas sûr qu'on y retrouve grand chose de neuf.) Effectivement, c'est dans ~/.local/share/xorg/Xorg.0.log [42.746] (EE) modeset(0): [DRI2] No driver mapping found for PCI device 0x8086 / 0x8a56 [42.746] (EE) modeset(0): Failed to initialize the DRI2 extension. c'est à cause de mon /etc/modprobe.d/i915.conf ? il contient : # cf https://wiki.archlinux.org/index.php/Intel_graphics options i915 enable_guc=2 > Certains acharnés ont testé différents réglages du module[1]. > Personnellement, je n'ai rien vu de franchement documenté quant > à ces options, du coup je me suis gardé de les recommander en > premier lieu ; mais qui sait, pour information. > > [1]: un exemple parmi beaucoup d'autre sur le pilote i915 : > https://bbs.archlinux.org/viewtopic.php?pid=1903409#p1903409 Je vais tester, avant je vais essayer d'autres choses vues sur https://wiki.archlinux.org/title/Intel_graphics https://hobo.house/2018/05/18/fix-for-intel-i915-gpu-freeze-on-recent-linux-kernels/ https://www.reddit.com/r/debian/comments/kn90rn/intel_iris_plus_655_igpu_crashing_often_i915/ https://linuxreviews.org/Intel_graphics https://linuxreviews.org/Linux_Kernel_5.5_Will_Not_Fix_The_Frequent_Intel_GPU_Hangs_In_Recent_Kernels J'ai commencé par mettre les options intel_idle.max_cstate=1 i915.enable_dc=0 En tout cas on est nombreux à avoir le pb, et ça doit pas être trivial car ça traîne depuis plus d'un an, et les nombreuses versions du noyau parues depuis n'ont pas réglé le pb. Et dire que j'avais choisi cette machine justement parce que c'était du chipset intel sans carte graphique supplémentaire :-/ -- Daniel Ce qui est simple est faux ; ce qui est compliqué est inutilisable. Paul Valéry
Re: Plantages Xorg (i915, context reset due to GPU hang)
Bonjour Daniel, Daniel Caillibaud, on 2021-06-15: > Le 14/06/21 à 13:25, Daniel Caillibaud a écrit : > > Je teste ça et je vous dis dans qq j si ça a réglé le pb. > > Caramba encore raté :'-( > > ça tient 4~5h : > > Jun 14 19:43:01 dell kernel: [22501.752663] i915 :00:02.0: [drm] > Resetting rcs0 for preemption time out > Jun 14 19:43:01 dell kernel: [22501.752684] i915 :00:02.0: [drm] > Xorg[1988] context reset due to GPU hang > Jun 14 19:43:01 dell kernel: [22501.763575] i915 :00:02.0: [drm] GPU > HANG: ecode 11:1:86dd, in Xorg [1988] > > Jun 15 14:11:02 dell kernel: [19659.973156] i915 :00:02.0: [drm] > Resetting rcs0 for preemption time out > Jun 15 14:11:02 dell kernel: [19659.973181] i915 :00:02.0: [drm] > Xorg[2180] context reset due to GPU hang > Jun 15 14:11:02 dell kernel: [19659.980708] i915 :00:02.0: [drm] GPU > HANG: ecode 11:1:86dd, in Xorg [2180] Argh, dommage, bon au moins, ça valait le coup d'essayer… […] > /var/log/Xorg.0.log est vide Ça me surprend, en temps normal il y a toujours beaucoup de verbiage dans les journaux d'Xorg. Il a été remis à zéro, démarré en tant qu'utilisateur (~/.local/share/xorg/Xorg.0.log), ou démarré sur un autre display (Xorg.1.log) ? (Simple curiosité, pas sûr qu'on y retrouve grand chose de neuf.) > Pas encore pris le temps de me replonger dans tous les threads qui causent > de plantages i915, je vais essayer de prendre qq h pour le faire (même si je > ferais probablement mieux de prendre ces heures pour chercher un autre pc > sur le bon coin) Effectivement, quand quelque chose dans le matériel ne suit pas, on peut faire tout ce qu'on veut du côté du logiciel, il y a un moment ou ça finit par coincer. À vous de voir le temps que vous voulez y passer. Certains acharnés ont testé différents réglages du module[1]. Personnellement, je n'ai rien vu de franchement documenté quant à ces options, du coup je me suis gardé de les recommander en premier lieu ; mais qui sait, pour information. [1]: un exemple parmi beaucoup d'autre sur le pilote i915 : https://bbs.archlinux.org/viewtopic.php?pid=1903409#p1903409 Bonne journée, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/tty1, please excuse my verbosity. signature.asc Description: PGP signature
Re: Plantages Xorg (i915, context reset due to GPU hang)
Le 14/06/21 à 13:25, Daniel Caillibaud a écrit : > Je teste ça et je vous dis dans qq j si ça a réglé le pb. Caramba encore raté :'-( ça tient 4~5h : Jun 14 19:43:01 dell kernel: [22501.752663] i915 :00:02.0: [drm] Resetting rcs0 for preemption time out Jun 14 19:43:01 dell kernel: [22501.752684] i915 :00:02.0: [drm] Xorg[1988] context reset due to GPU hang Jun 14 19:43:01 dell kernel: [22501.763575] i915 :00:02.0: [drm] GPU HANG: ecode 11:1:86dffffd, in Xorg [1988] Jun 15 14:11:02 dell kernel: [19659.973156] i915 :00:02.0: [drm] Resetting rcs0 for preemption time out Jun 15 14:11:02 dell kernel: [19659.973181] i915 :00:02.0: [drm] Xorg[2180] context reset due to GPU hang Jun 15 14:11:02 dell kernel: [19659.980708] i915 :00:02.0: [drm] GPU HANG: ecode 11:1:86dffffd, in Xorg [2180] après un boot un `grep i915 /vl/kern.log` me donne ça Jun 15 14:12:15 dell kernel: [1.325096] i915 :00:02.0: vgaarb: deactivate vga console Jun 15 14:12:15 dell kernel: [1.357265] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem Jun 15 14:12:15 dell kernel: [1.357742] i915 :00:02.0: [drm] Finished loading DMC firmware i915/icl_dmc_ver1_09.bin (v1.9) Jun 15 14:12:15 dell kernel: [1.395645] i915 :00:02.0: [drm] GuC firmware i915/icl_guc_49.0.1.bin version 49.0 submission:disabled Jun 15 14:12:15 dell kernel: [1.395649] i915 :00:02.0: [drm] HuC firmware i915/icl_huc_9.0.0.bin version 9.0 authenticated:yes Jun 15 14:12:15 dell kernel: [1.402366] [drm] Initialized i915 1.6.0 20201103 for :00:02.0 on minor 0 Jun 15 14:12:15 dell kernel: [1.438734] fbcon: i915drmfb (fb0) is primary device Jun 15 14:12:15 dell kernel: [2.606944] i915 :00:02.0: [drm] fb0: i915drmfb frame buffer device Jun 15 14:12:15 dell kernel: [ 12.669407] snd_hda_intel :00:1f.3: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) uname -a Linux dell 5.12.9 #2 SMP Wed Jun 9 22:51:28 CEST 2021 x86_64 GNU/Linux /var/log/Xorg.0.log est vide Pas encore pris le temps de me replonger dans tous les threads qui causent de plantages i915, je vais essayer de prendre qq h pour le faire (même si je ferais probablement mieux de prendre ces heures pour chercher un autre pc sur le bon coin) -- Daniel es de porter des lunettes de soleil est quand même un excellent commercial.
Re: Plantages Xorg (i915, context reset due to GPU hang)
Bonsoir, Le 11/06/21 à 23:30, Étienne Mollier a écrit : > J'ai pris un peu de temps pour faire le tour du web avec un > moteur de recherche, et quelque mots clés avec ces symptômes. > J'ai vu ici[1] ou là[2] que désactiver l'iommu avait aidé dans > des cas à vue de nez à peu près similaires à stabiliser la > machine. Merci bcp pour avoir pris ce temps pour chercher/trouver/expliquer. J'avais cherché à partir de gpu hang, sans rien trouver qui me semblait pertinent, probablement parce que ces histoires de hardware me dépassent un peu (et j'ai du mal à m'y intéresser pour apprendre). > Dans le cas de l'iommu, il y a plusieurs options : > > - soit la désactiver au niveau de la configuration "Bios" de > la carte mère ; > - soit au démarrage, en passant l'argument intel_iommu=off au > noyau linux dans grub ; > - ou faire sauter CONFIG_INTEL_IOMMU, en restant dans les > options exposées par le .config. Merci bcp ! Je teste ça et je vous dis dans qq j si ça a réglé le pb. Au cas où d'autres auraient le pb et verraient ce thread dans les archives, j'ai choisi l'option grub (la plus rapide à tester) avec - ajouter l'option dans la variable GRUB_CMDLINE_LINUX de /etc/default/grub, dans mon cas j'ai remplacé GRUB_CMDLINE_LINUX="" par GRUB_CMDLINE_LINUX="intel_iommu=off" (mais si y'avait déjà les options xxx et yyy ça donnerait GRUB_CMDLINE_LINUX="xxx yyy intel_iommu=off") - relancer un `update-grub` - vérifier que ça donne ce que l'on voulait avec `grep mmu /boot/grub/grub.cfg` (qui doit retourner cette option pour chaque entrée de grub) -- Daniel Il y a quelqu'un sans qui tout ce que j'ai fait jusqu'à présent n'aurait pas été possible: MOI. Philippe Geluck, Le chat
Re: Plantages Xorg (i915, context reset due to GPU hang)
Bonsoir Daniel, Daniel Caillibaud, on 2021-06-10: > Depuis que j'utilise cette machine (dell 3793, i5-1035G1, chipset graphique > intel) > avec buster, j'ai plein de plantages (wifi & i915 depuis le début, un autre > pb de > plantage cpu a été réglé par une mise à jour de intel-microcode), jusque là > c'était > pénible mais gérable. > > hier ça ne tenait pas plus de 10min :-/ > > Jun 8 14:54:42 dell kernel: [35103.222690] i915 :00:02.0: [drm] > Resetting rcs0 for preemption time out > Jun 8 14:54:42 dell kernel: [35103.222709] i915 :00:02.0: [drm] > Xorg[2118] context reset due to GPU hang > Jun 8 14:54:42 dell kernel: [35103.238726] i915 :00:02.0: [drm] GPU > HANG: ecode 11:1:86dd, in Xorg [2118] J'ai pris un peu de temps pour faire le tour du web avec un moteur de recherche, et quelque mots clés avec ces symptômes. J'ai vu ici[1] ou là[2] que désactiver l'iommu avait aidé dans des cas à vue de nez à peu près similaires à stabiliser la machine. [1]: https://bbs.archlinux.org/viewtopic.php?id=230115 [2]: https://forums.gentoo.org/viewtopic-p-8052822.html D'autres personnes ont tenté de retoucher à diverses variables ayant trait au pilote i915[3]. Je ne les ai pas trouvées dans la documentation du noyau, donc je ne sais pas trop ce que vaut ce genre de manipulations, mais ça a l'air d'avoir aidé du monde. [3]: https://unix.stackexchange.com/questions/401746/drm-i915-resetting-chip-after-gpu-hang > J'utilisais linux-image-5.10.0-0.bpo.5-amd64 > > J'ai tenté de recompiler le tout dernier 5.12.9 avec make deb-pkg (récup du > .config > du 5.10 et conf par défaut pour toutes les nouvelles options), mais ça n'a > rien changé. > > Le seul truc qui avait changé hier matin est > Upgrade: linux-kbuild-5.10:amd64 (5.10.24-1~bpo10+1, 5.10.40-1~bpo10+1) > > => viré linux-kbuild-5.10 virtualbox-6.1 linux-headers-amd64 > => je suis revenu à l'état antérieur, un plantage de temps en temps. Au vu de la mention de virtualbox qui a sauté, l'iommu me semble assez suspecte. C'est un mécanisme d'isolation des plages mémoire des périphériques vis-à-vis du système hôte, pour les exposer directement aux machines virtuelles. J'ai déjà eu l'occasion de me mordre les doigts sur des histoires d'iommu dans des contextes un peu différent, du coup je sais que ce mécano peut rendre une machine inutilisable s'il n'est pas correctement pris en charge. Si les pilotes virtualbox ont tenté de manipuler l'iommu dès le démarrage de la machine, alors peut-être que ça a pu amplifier le problème ? > D'habitude je bosse avec un écran externe (même résolution que l'écran du > portable), depuis hier je suis > sans écran externe (cf autre thread, pb de résolution), et ça n'a rien changé > pour les plantages X > > Y'a t'il des modifs à essayer dans le .config du kernel pour tenter > d'améliorer la situation ? > > Ou dans une autre conf qq part ? Dans le cas de l'iommu, il y a plusieurs options : - soit la désactiver au niveau de la configuration "Bios" de la carte mère ; - soit au démarrage, en passant l'argument intel_iommu=off au noyau linux dans grub ; - ou faire sauter CONFIG_INTEL_IOMMU, en restant dans les options exposées par le .config. Pour être honnête, cette histoire d'iommu reste un peu du pif de ma part, m'enfin si ça peut aider… Bonne soirée, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. signature.asc Description: PGP signature
Plantages Xorg (i915, context reset due to GPU hang)
Bonjour, Depuis que j'utilise cette machine (dell 3793, i5-1035G1, chipset graphique intel) avec buster, j'ai plein de plantages (wifi & i915 depuis le début, un autre pb de plantage cpu a été réglé par une mise à jour de intel-microcode), jusque là c'était pénible mais gérable. hier ça ne tenait pas plus de 10min :-/ Jun 8 14:54:42 dell kernel: [35103.222690] i915 :00:02.0: [drm] Resetting rcs0 for preemption time out Jun 8 14:54:42 dell kernel: [35103.222709] i915 0000:00:02.0: [drm] Xorg[2118] context reset due to GPU hang Jun 8 14:54:42 dell kernel: [35103.238726] i915 :00:02.0: [drm] GPU HANG: ecode 11:1:86dd, in Xorg [2118] J'utilisais linux-image-5.10.0-0.bpo.5-amd64 J'ai tenté de recompiler le tout dernier 5.12.9 avec make deb-pkg (récup du .config du 5.10 et conf par défaut pour toutes les nouvelles options), mais ça n'a rien changé. Le seul truc qui avait changé hier matin est Upgrade: linux-kbuild-5.10:amd64 (5.10.24-1~bpo10+1, 5.10.40-1~bpo10+1) => viré linux-kbuild-5.10 virtualbox-6.1 linux-headers-amd64 => je suis revenu à l'état antérieur, un plantage de temps en temps. D'habitude je bosse avec un écran externe (même résolution que l'écran du portable), depuis hier je suis sans écran externe (cf autre thread, pb de résolution), et ça n'a rien changé pour les plantages X Y'a t'il des modifs à essayer dans le .config du kernel pour tenter d'améliorer la situation ? Ou dans une autre conf qq part ? (j'ai pas de xorg.conf, tout vient de l'install debian par défaut) Voici ce que j'ai dans mon .config : egrep -i -E '(drm|i915)' linux-5.12.9/.config CONFIG_DRM=m CONFIG_DRM_MIPI_DSI=y CONFIG_DRM_DP_AUX_CHARDEV=y # CONFIG_DRM_DEBUG_SELFTEST is not set CONFIG_DRM_KMS_HELPER=m CONFIG_DRM_KMS_FB_HELPER=y # CONFIG_DRM_DEBUG_DP_MST_TOPOLOGY_REFS is not set CONFIG_DRM_FBDEV_EMULATION=y CONFIG_DRM_FBDEV_OVERALLOC=100 # CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set CONFIG_DRM_LOAD_EDID_FIRMWARE=y CONFIG_DRM_DP_CEC=y CONFIG_DRM_TTM=m CONFIG_DRM_VRAM_HELPER=m CONFIG_DRM_TTM_HELPER=m CONFIG_DRM_GEM_SHMEM_HELPER=y CONFIG_DRM_SCHED=m CONFIG_DRM_I2C_CH7006=m CONFIG_DRM_I2C_SIL164=m # CONFIG_DRM_I2C_NXP_TDA998X is not set # CONFIG_DRM_I2C_NXP_TDA9950 is not set CONFIG_DRM_RADEON=m # CONFIG_DRM_RADEON_USERPTR is not set CONFIG_DRM_AMDGPU=m CONFIG_DRM_AMDGPU_SI=y CONFIG_DRM_AMDGPU_CIK=y CONFIG_DRM_AMDGPU_USERPTR=y # CONFIG_DRM_AMDGPU_GART_DEBUGFS is not set CONFIG_DRM_AMD_ACP=y CONFIG_DRM_AMD_DC=y CONFIG_DRM_AMD_DC_DCN=y CONFIG_DRM_AMD_DC_HDCP=y CONFIG_DRM_AMD_DC_SI=y CONFIG_DRM_NOUVEAU=m CONFIG_DRM_NOUVEAU_BACKLIGHT=y CONFIG_DRM_I915=m CONFIG_DRM_I915_FORCE_PROBE="" CONFIG_DRM_I915_CAPTURE_ERROR=y CONFIG_DRM_I915_COMPRESS_ERROR=y CONFIG_DRM_I915_USERPTR=y CONFIG_DRM_I915_GVT=y CONFIG_DRM_I915_GVT_KVMGT=m # drm/i915 Debugging # CONFIG_DRM_I915_WERROR is not set # CONFIG_DRM_I915_DEBUG is not set # CONFIG_DRM_I915_DEBUG_MMIO is not set # CONFIG_DRM_I915_SW_FENCE_DEBUG_OBJECTS is not set # CONFIG_DRM_I915_SW_FENCE_CHECK_DAG is not set # CONFIG_DRM_I915_DEBUG_GUC is not set # CONFIG_DRM_I915_SELFTEST is not set # CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS is not set # CONFIG_DRM_I915_DEBUG_VBLANK_EVADE is not set # CONFIG_DRM_I915_DEBUG_RUNTIME_PM is not set # end of drm/i915 Debugging # drm/i915 Profile Guided Optimisation CONFIG_DRM_I915_FENCE_TIMEOUT=1 CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND=250 CONFIG_DRM_I915_HEARTBEAT_INTERVAL=2500 CONFIG_DRM_I915_PREEMPT_TIMEOUT=640 CONFIG_DRM_I915_MAX_REQUEST_BUSYWAIT=8000 CONFIG_DRM_I915_STOP_TIMEOUT=100 CONFIG_DRM_I915_TIMESLICE_DURATION=1 # end of drm/i915 Profile Guided Optimisation CONFIG_DRM_VGEM=m # CONFIG_DRM_VKMS is not set CONFIG_DRM_VMWGFX=m CONFIG_DRM_VMWGFX_FBCON=y CONFIG_DRM_GMA500=m CONFIG_DRM_GMA600=y CONFIG_DRM_UDL=m CONFIG_DRM_AST=m CONFIG_DRM_MGAG200=m CONFIG_DRM_QXL=m CONFIG_DRM_BOCHS=m CONFIG_DRM_VIRTIO_GPU=m CONFIG_DRM_PANEL=y # CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN is not set CONFIG_DRM_BRIDGE=y CONFIG_DRM_PANEL_BRIDGE=y # CONFIG_DRM_ANALOGIX_ANX78XX is not set # CONFIG_DRM_ETNAVIV is not set CONFIG_DRM_CIRRUS_QEMU=m # CONFIG_DRM_GM12U320 is not set # CONFIG_TINYDRM_HX8357D is not set # CONFIG_TINYDRM_ILI9225 is not set # CONFIG_TINYDRM_ILI9341 is not set # CONFIG_TINYDRM_ILI9486 is not set # CONFIG_TINYDRM_MI0283QT is not set # CONFIG_TINYDRM_REPAPER is not set # CONFIG_TINYDRM_ST7586 is not set # CONFIG_TINYDRM_ST7735R is not set CONFIG_DRM_XEN=y CONFIG_DRM_XEN_FRONTEND=m CONFIG_DRM_VBOXVIDEO=m # CONFIG_DRM_LEGACY is not set CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y CONFIG_SND_HDA_I915=y -- Daniel Mes clients sont libres de choisir la couleur de leur voiture à condition qu'ils la veuillent noire. Henri Ford
Re: Xorg
Les trois sont bien installé. J'ai finalement trouvé. j'ai modifié le fichier /etc/security/limits.conf j'y ai ajouté les deux lignes suivantes: * soft memlock 262144 * hard memlock 262144 Cordialement
Re: Xorg
Klaus Becker a écrit : 'soir, Bonjour, est-ce que un des 3 packetages suivants est installés : -xserver-xorg-video-ati - serveur X pour X.org – enveloppe pour les pilotes d'affichage AMD/ATI -xserver-xorg-video-radeon - serveur X X.Org − pilote vidéo AMD/ATI Radeon - firmware-amd-graphics - Binary firmware for AMD/ATI graphics chips Dans le doute, j'essayerais les 3 Les trois sont bien installé. Cordialement
Re: Xorg
Le 13/02/2021 à 15:31, zut...@laposte.net a écrit : > > Bonjour, > > Suite à re-installation d'une Debian stable sur un ordinateur fixe, je > n'arrive plus à lancer Xorg. > > J'ai essayé de créer un xorg.conf, mais cela n'apporte pas > d'amélioration notable. > > Je précise que l'installation c'est effectué a l'aide de l'interface > graphique et que donc, ca doit bien marcher d'une façon ou d'une > autre. ;-( > > Si vous aviez une suggestion ou une remarque Pour que ta carte graphique fonctionne, il faut que le bon pilote soit installé, et aussi parfois le bon firmware. Commence par activer les depots contrib et non-free https://debian-facile.org/doc:systeme:apt:sources.list:sources.list-non-free il faut adapter ce qui est la dedans en fonction de la version de debian que tu a choisie. Pour le pilote : https://debian-facile.org/doc:materiel:cartes-graphique:cartes-graphique Pour le firmware : https://debian-facile.org/doc:materiel:firmwares-non-libres
Re: Xorg
Le 13/02/2021 à 15:31, zut...@laposte.net a écrit : Bonjour, Suite à re-installation d'une Debian stable sur un ordinateur fixe, je n'arrive plus à lancer Xorg. J'ai essayé de créer un xorg.conf, mais cela n'apporte pas d'amélioration notable. Je précise que l'installation c'est effectué a l'aide de l'interface graphique et que donc, ca doit bien marcher d'une façon ou d'une autre. ;-( Si vous aviez une suggestion ou une remarque voici mon fichier Xorg.0.log sans aucun fichier xorg.conf: [ 3407.273] X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 [ 3407.275] Build Operating System: Linux 4.19.0-12-amd64 x86_64 Debian [ 3407.276] Current Operating System: Linux Bureau 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 [ 3407.276] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-14-amd64 root=/dev/mapper/coquille-root ro quiet [ 3407.278] Build Date: 01 December 2020 05:59:57PM [ 3407.278] xorg-server 2:1.20.4-1+deb10u2 (https://www.debian.org/support) [ 3407.279] Current version of pixman: 0.36.0 [ 3407.280] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 3407.280] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 3407.282] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Feb 13 15:23:25 2021 [ 3407.282] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 3407.282] (==) No Layout section. Using the first Screen section. [ 3407.282] (==) No screen section available. Using defaults. [ 3407.282] (**) |-->Screen "Default Screen Section" (0) [ 3407.282] (**) | |-->Monitor "" [ 3407.283] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 3407.283] (==) Automatically adding devices [ 3407.283] (==) Automatically enabling devices [ 3407.283] (==) Automatically adding GPU devices [ 3407.283] (==) Max clients allowed: 256, resource mask: 0x1f [ 3407.283] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 3407.283] Entry deleted from font path. [ 3407.283] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 3407.283] (==) ModulePath set to "/usr/lib/xorg/modules" [ 3407.283] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 3407.283] (II) Loader magic: 0x55671aba1e20 [ 3407.283] (II) Module ABI versions: [ 3407.283] X.Org ANSI C Emulation: 0.4 [ 3407.283] X.Org Video Driver: 24.0 [ 3407.283] X.Org XInput driver : 24.1 [ 3407.283] X.Org Server Extension : 10.0 [ 3407.283] (++) using VT number 2 [ 3407.285] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_32 [ 3407.286] (--) PCI:*(1@0:0:0) 1002:6611:1b0a:90d3 rev 0, Mem @ 0xe000/268435456, 0xf7e00000/262144, I/O @ 0xe000/256, BIOS @ 0x/131072 [ 3407.286] (II) LoadModule: "glx" [ 3407.286] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 3407.287] (II) Module glx: vendor="X.Org Foundation" [ 3407.287] compiled for 1.20.4, module version = 1.0.0 [ 3407.287] ABI class: X.Org Server Extension, version 10.0 [ 3407.287] (==) Matched ati as autoconfigured driver 0 [ 3407.287] (==) Matched modesetting as autoconfigured driver 1 [ 3407.287] (==) Matched fbdev as autoconfigured driver 2 [ 3407.287] (==) Matched vesa as autoconfigured driver 3 [ 3407.287] (==) Assigned the driver to the xf86ConfigLayout [ 3407.287] (II) LoadModule: "ati" [ 3407.287] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so [ 3407.294] (II) Module ati: vendor="X.Org Foundation" [ 3407.294] compiled for 1.20.4, module version = 19.0.1 [ 3407.294] Module class: X.Org Video Driver [ 3407.294] ABI class: X.Org Video Driver, version 24.0 [ 3407.358] (II) LoadModule: "radeon" [ 3407.358] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so [ 3407.380] (II) Module radeon: vendor="X.Org Foundation" [ 3407.380] compiled for 1.20.4, module version = 19.0.1 [ 3407.380] Module class: X.Org Video Driver [ 3407.380] ABI class: X.Org Video Driver, version 24.0 [ 3407.380] (II) LoadModule: "modesetting" [ 3407.380] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [ 3407.393] (II) Module modesetting: vendor="X.Org Foundation" [ 3407.393] compiled for 1.20.4, module ve
Xorg
Bonjour, Suite à re-installation d'une Debian stable sur un ordinateur fixe, je n'arrive plus à lancer Xorg. J'ai essayé de créer un xorg.conf, mais cela n'apporte pas d'amélioration notable. Je précise que l'installation c'est effectué a l'aide de l'interface graphique et que donc, ca doit bien marcher d'une façon ou d'une autre. ;-( Si vous aviez une suggestion ou une remarque voici mon fichier Xorg.0.log sans aucun fichier xorg.conf: [ 3407.273] X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 [ 3407.275] Build Operating System: Linux 4.19.0-12-amd64 x86_64 Debian [ 3407.276] Current Operating System: Linux Bureau 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 [ 3407.276] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-14-amd64 root=/dev/mapper/coquille-root ro quiet [ 3407.278] Build Date: 01 December 2020 05:59:57PM [ 3407.278] xorg-server 2:1.20.4-1+deb10u2 (https://www.debian.org/support) [ 3407.279] Current version of pixman: 0.36.0 [ 3407.280] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 3407.280] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 3407.282] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Feb 13 15:23:25 2021 [ 3407.282] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 3407.282] (==) No Layout section. Using the first Screen section. [ 3407.282] (==) No screen section available. Using defaults. [ 3407.282] (**) |-->Screen "Default Screen Section" (0) [ 3407.282] (**) | |-->Monitor "<default monitor>" [ 3407.283] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 3407.283] (==) Automatically adding devices [ 3407.283] (==) Automatically enabling devices [ 3407.283] (==) Automatically adding GPU devices [ 3407.283] (==) Max clients allowed: 256, resource mask: 0x1f [ 3407.283] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 3407.283] Entry deleted from font path. [ 3407.283] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 3407.283] (==) ModulePath set to "/usr/lib/xorg/modules" [ 3407.283] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 3407.283] (II) Loader magic: 0x55671aba1e20 [ 3407.283] (II) Module ABI versions: [ 3407.283] X.Org ANSI C Emulation: 0.4 [ 3407.283] X.Org Video Driver: 24.0 [ 3407.283] X.Org XInput driver : 24.1 [ 3407.283] X.Org Server Extension : 10.0 [ 3407.283] (++) using VT number 2 [ 3407.285] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_32 [ 3407.286] (--) PCI:*(1@0:0:0) 1002:6611:1b0a:90d3 rev 0, Mem @ 0xe000/268435456, 0xf7e0/262144, I/O @ 0xe000/256, BIOS @ 0x/131072 [ 3407.286] (II) LoadModule: "glx" [ 3407.286] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 3407.287] (II) Module glx: vendor="X.Org Foundation" [ 3407.287] compiled for 1.20.4, module version = 1.0.0 [ 3407.287] ABI class: X.Org Server Extension, version 10.0 [ 3407.287] (==) Matched ati as autoconfigured driver 0 [ 3407.287] (==) Matched modesetting as autoconfigured driver 1 [ 3407.287] (==) Matched fbdev as autoconfigured driver 2 [ 3407.287] (==) Matched vesa as autoconfigured driver 3 [ 3407.287] (==) Assigned the driver to the xf86ConfigLayout [ 3407.287] (II) LoadModule: "ati" [ 3407.287] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so [ 3407.294] (II) Module ati: vendor="X.Org Foundation" [ 3407.294] compiled for 1.20.4, module version = 19.0.1 [ 3407.294] Module class: X.Org Video Driver [ 3407.294] ABI class: X.Org Video Driver, version 24.0 [ 3407.358] (II) LoadModule: "radeon" [ 3407.358] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so [ 3407.380] (II) Module radeon: vendor="X.Org Foundation" [ 3407.380] compiled for 1.20.4, module version = 19.0.1 [ 3407.380] Module class: X.Org Video Driver [ 3407.380] ABI class: X.Org Video Driver, version 24.0 [ 3407.380] (II) LoadModule: "modesetting" [ 3407.380] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [ 3407.393] (II) Module modesetting: vendor="X.Org Foundation" [ 3407.393] compiled for 1.20.4, module version = 1.20.4 [ 3407.393] M
Re: Xorg tourne à 100 % du CPU ("ioctl(13, DRM_IOCTL_I915_GEM_CREATE...
Le Fri, 20 Nov 2020 13:28:58 +0100, Stephane Bortzmeyer a écrit : > Une idée ? Peut-être essayer mettre a jour le firmware chez intel ? https://downloadcenter.intel.com/fr/product/80939/Solution-graphique
Re: Xorg tourne à 100 % du CPU ("ioctl(13, DRM_IOCTL_I915_GEM_CREATE...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Étienne Mollier a écrit : > Bonjour Stéphane, > > Stephane Bortzmeyer, on 2020-11-20 13:28:58 +0100: >> Soit une machine Debian "desktop" en 10.6 buster. >> >> De temps en temps, le serveur X ne répond plus à rien (ni >> souris, ni clavier). En se connectant depuis une autre machine, >> on voit qu'il tourne à 100 % du CPU et strace montre qu'il boucle >> sur : >> >> ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc8724) = 0 ioctl(13, >> DRM_IOCTL_I915_GEM_EXECBUFFER2, 0xbfcc878c) = 0 ioctl(13, >> DRM_IOCTL_I915_GEM_BUSY, 0xbfcc878c) = 0 ioctl(13, >> DRM_IOCTL_I915_GEM_CREATE, 0xbfcc877c) = 0 ioctl(13, >> DRM_IOCTL_GEM_CLOSE, 0xbfcc86f4) = 0 ioctl(13, >> DRM_IOCTL_I915_GEM_BUSY, 0xbfcc8724) = 0 ioctl(13, >> DRM_IOCTL_I915_GEM_EXECBUFFER2, 0xbfcc878c) = 0 ioctl(13, >> DRM_IOCTL_I915_GEM_BUSY, 0xbfcc878c) = 0 ioctl(13, >> DRM_IOCTL_I915_GEM_CREATE, 0xbfcc877c) = 0 ioctl(13, >> DRM_IOCTL_GEM_CLOSE, 0xbfcc86f4) = 0 ... >> >> Une idée ? > > Je n'ai pas franchement d'idées pour l'instant. Le résultat le > plus proche que j'ai pu trouver en rapport avec des ioctl i915 GEM > est une fiche CVE qui concerne initialement Linux 4.15 pour > Ubuntu: > > https://security-tracker.debian.org/tracker/CVE-2019-12881 > > Quelques questions en vrac: > > - Est-ce que du côté du noyau, via `dmesg`, les modules i915 ou > drm renvoient des erreurs lors de ce genre de panne ? - Est-ce que > les versions antérieures du noyau de Buster ont déjà provoqué ce > genre de symptômes ? > > Si c'est le cas, alors le problème se situerait du côté de Linux ; > sinon adresser un rapport de bogue auprès du paquet > "xserver-xorg-video-intel" me semblerait être un bon point de > départ. > > Est-ce que démarrer la machine avec l'option "nomodeset" peut > stabiliser le serveur X ? L'idée est de mettre la partie DRM hors > circuit, mais au prix de sacrifier l'accélération graphique. Ce > n'est pas idéal, mais ça peut permettre de travailler le temps > dépanner. Et si la panne se reproduit dans cette configuration, > alors ça pourra être intéressant de voir comment évoluent les > appels système fournis par `strace`. Bonsoir, Je ne vais pas aider beaucoup, mais j'ai un vague souvenir d'avoir eu la même chose il y a très longtemps. Une pluie d'interruptions mal traitées en provenance de l'économiseur d'écran. Voir si ça ne pourrait pas être le même genre de gag : un programme particulier qui monopolise le serveur X en le bourrant d'interruptions. Dans mon cas, c'était aussi une video intel (i7-4470 de mémoire). Pour la correction, pour ma part, c'était un serveur, ça s'est soldé avec un retrait de X. Que dit un simple top ? JKB -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEq4YCoAJMwLElZVYXOAfo0lKQ8+cFAl+4IAAACgkQOAfo0lKQ 8+e8JA//WzMF/Do5PBGINo/xmeDPWZ5TCO8wiH1l5Ks92Uz51Xjp/qW3BJ1DwF/i szi9esIAEaT3agxhERUyuxTxb0cq6K6uvT0G+oky0mKW6ZdcrP23/TlQTpQ+yfsc 9t1E3QHxZjlK/2mNd00ZgnqATHMOzJRZs4QjK2YBiMwsqaT2w0yI0QF2MfIitA0q g0cV37/vl2UoiGxztlvoOBPu+6Dl+kragdewFNXRD/SZOFEy6/X9mAIMyccwsDvm xvlzQTNcJMeHVcVSjklTC82a5LKNAyb/bZcp89vEw9IDKefnuuz1035ifG5Fo8CL 9QN5Jd3FOHkr1P9fe+vXYO9quUpdiXYCnqxvnjVA/0KVJxxNFNO1aAP18ZS9VeIW 041Sn4y9fWuqOReLpTdz5oefSISHPV0DVoZ93wjTJwNZRCpJj98amo/WJcqSt/yH 0Q52OltaRbtX4r2MR7MoubK+BPx/8/YPYLfnZv+19tMdM1Xd28LmqQEM2+RiCDqv 6oWHDBMZMZIHbgQFgbuI+QpM8EPPD8f7xHXxTPNnANy/bbXX1ZW7faiMDSfJMt35 +k2UeLqqmtSZ71E/3AP/XCy6ewEphSUkWtYclG4T7K5VKqDLTnRkYLlHPY/R2bq6 AZfVwrFSMCmHfE7WYGA9uF50qHrLmnnuO//GeZWV3saVc6l/i68= =jZT3 -END PGP SIGNATURE-
Re: Xorg tourne à 100 % du CPU ("ioctl(13, DRM_IOCTL_I915_GEM_CREATE...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Étienne Mollier a écrit : Bonsoir, Je ne vais pas aider beaucoup, mais j'ai un vague souvenir d'avoir eu la même chose il y a très longtemps. Une pluie d'interruptions mal traitées en provenance de l'économiseur d'écran. Voir si ça ne pourrait pas être le même genre de gag : un programme particulier qui monopolise le serveur X en le bourrant d'interruptions. Dans mon cas, c'était aussi une video intel (i7-4470 de mémoire). Pour la correction, pour ma part, c'était un serveur, ça s'est soldé avec un retrait de X. Que dit un simple top ? JKB -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEq4YCoAJMwLElZVYXOAfo0lKQ8+cFAl+4H/wACgkQOAfo0lKQ 8+dH/w//bRTIcwuSp5T7lj+2SH3u7Z/TK8qDC45/iHFWA7HZgssAh+wg+hXl+I4q fy211jQHdMvQ/OoKPUBmJnsQIZ60W6/92tbCFP6ZudV+hrXIPLn0KV/o2BpEeiTo rBpoqNE2AUfcCXI18WwRRVi1DDaPIolz+WkJMWmVgUw8Bb0SbmZ5JN6qCfpQ9O8d B8fOj+ujTeCZhOUtB7UMXAA/jhUoFJ/9jWL2kafe/2JW6jIZGkDfMxYtImNQoID7 4WWP7a24JD6kuAK3RNe5o0o4VsBo9hmyriOtDbF85Wk3eytat5BYECFQawTX8BCi Ypb0bJJ7C3UwSaQN0S/jywF7YTpT3L5nZ5o5VJuZHl/soW79x4egGWHtWOfv9MA/ 0GD6fcHP58GY5fV7bLLShFwS/pkE5phPi3O3+gTuuL58xpykwRJWZbIG0Ccf5F/V I1kwa11W9TMUuwoEPUzdDbSG+1KGP/FDCNO+OzIsDIzJOwrNiqxUSZssR0kBDTV2 3iEmH9n6Q0UBjRoxjU/qeBKX05BtyI2nX17IocZnHy8Ufq3u+aSrcL+cVYi8TO6z sVnvzE/hRPbAx7jRYhFshsOI3xQ+ZNK6eJxg/Lg2+GqPiP7E9KYoUzhdrVSdxfD6 Wl77nwNhGoIxvr6isM2S0macjvNAoIFCQQfL7/02WtE25sqy0uw= =f5m6 -END PGP SIGNATURE-
Re: Xorg tourne à 100 % du CPU ("ioctl(13, DRM_IOCTL_I915_GEM_CREATE...
Bonjour Stéphane, Stephane Bortzmeyer, on 2020-11-20 13:28:58 +0100: > Soit une machine Debian "desktop" en 10.6 buster. > > De temps en temps, le serveur X ne répond plus à rien (ni souris, ni > clavier). En se connectant depuis une autre machine, on voit qu'il > tourne à 100 % du CPU et strace montre qu'il boucle sur : > > ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc8724) = 0 > ioctl(13, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0xbfcc878c) = 0 > ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc878c) = 0 > ioctl(13, DRM_IOCTL_I915_GEM_CREATE, 0xbfcc877c) = 0 > ioctl(13, DRM_IOCTL_GEM_CLOSE, 0xbfcc86f4) = 0 > ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc8724) = 0 > ioctl(13, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0xbfcc878c) = 0 > ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc878c) = 0 > ioctl(13, DRM_IOCTL_I915_GEM_CREATE, 0xbfcc877c) = 0 > ioctl(13, DRM_IOCTL_GEM_CLOSE, 0xbfcc86f4) = 0 > ... > > Une idée ? Je n'ai pas franchement d'idées pour l'instant. Le résultat le plus proche que j'ai pu trouver en rapport avec des ioctl i915 GEM est une fiche CVE qui concerne initialement Linux 4.15 pour Ubuntu: https://security-tracker.debian.org/tracker/CVE-2019-12881 Quelques questions en vrac: - Est-ce que du côté du noyau, via `dmesg`, les modules i915 ou drm renvoient des erreurs lors de ce genre de panne ? - Est-ce que les versions antérieures du noyau de Buster ont déjà provoqué ce genre de symptômes ? Si c'est le cas, alors le problème se situerait du côté de Linux ; sinon adresser un rapport de bogue auprès du paquet "xserver-xorg-video-intel" me semblerait être un bon point de départ. Est-ce que démarrer la machine avec l'option "nomodeset" peut stabiliser le serveur X ? L'idée est de mettre la partie DRM hors circuit, mais au prix de sacrifier l'accélération graphique. Ce n'est pas idéal, mais ça peut permettre de travailler le temps dépanner. Et si la panne se reproduit dans cette configuration, alors ça pourra être intéressant de voir comment évoluent les appels système fournis par `strace`. Bonne soirée, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/1, please excuse my verbosity. signature.asc Description: PGP signature
Xorg tourne à 100 % du CPU ("ioctl(13, DRM_IOCTL_I915_GEM_CREATE...
Soit une machine Debian "desktop" en 10.6 buster. De temps en temps, le serveur X ne répond plus à rien (ni souris, ni clavier). En se connectant depuis une autre machine, on voit qu'il tourne à 100 % du CPU et strace montre qu'il boucle sur : ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc8724) = 0 ioctl(13, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0xbfcc878c) = 0 ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc878c) = 0 ioctl(13, DRM_IOCTL_I915_GEM_CREATE, 0xbfcc877c) = 0 ioctl(13, DRM_IOCTL_GEM_CLOSE, 0xbfcc86f4) = 0 ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc8724) = 0 ioctl(13, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0xbfcc878c) = 0 ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc878c) = 0 ioctl(13, DRM_IOCTL_I915_GEM_CREATE, 0xbfcc877c) = 0 ioctl(13, DRM_IOCTL_GEM_CLOSE, 0xbfcc86f4) = 0 ... Une idée ? X.Org X Server 1.20.4 [ 13632.206] Build Operating System: Linux 4.19.0-10-amd64 i686 Debian [ 13632.206] Current Operating System: Linux 4.19.0-12-686-pae #1 SMP Debian 4.19.152-1 (2020-10-18 ) i686 [ 13632.206] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-686-pae root=UUID=1679ed76-c60d-49f8-b9c 2-a05aff7a8a08 ro quiet [ 13632.206] Build Date: 27 August 2020 08:51:48AM [ 13632.206] xorg-server 2:1.20.4-1+deb10u1 (https://www.debian.org/support)
Re: Toujours des plantage Xorg
Le 18/09/20 à 19:15, BERTRAND Joël a écrit : > Le dual screen ne serait-il pas pour quelque chose dans le problème ? Pas chez moi, ça vient de planter sans dual screen… -- Daniel Il est souvent trop tôt pour savoir s'il n'est pas trop tard. Pierre Dac
Re: Toujours des plantage Xorg
Le 21/09/20 à 17:51, Stephane Ascoet a écrit : > Le 21/09/2020 à 16:14, Haricophile a écrit : > > Un truc a installer une Gentoo malgré que l'absence de systemD ne leur > > permettent pas de contrôler la théière et l'arrosage du jardin au > > boot ? > > Bonjour, ou une Devuan... un debianiste y est chez lui :-) Si je tente autre chose, ce sera plutôt https://voidlinux.org/ ;-) -- Daniel Computers are like air conditioners, they stop working properly if you open Windows
Re: Toujours des plantage Xorg
Le 21/09/2020 à 16:14, Haricophile a écrit : Un truc a installer une Gentoo malgré que l'absence de systemD ne leur permettent pas de contrôler la théière et l'arrosage du jardin au boot ? Bonjour, ou une Devuan... un debianiste y est chez lui :-) -- Cordialement, Stephane Ascoet
Re: Toujours des plantage Xorg
Le Mon, 21 Sep 2020 11:27:56 +0200, BERTRAND Joël a écrit : > Personnellement, j'en suis à refuser de redémarrer des machines à > distance tellement les motifs de plantage au boot sont nombreux sur > des serveurs. J'ai même des machines (serveurs de bases de données) > qui se VAUTRENT au démarrage parce que systemd considère que les > grosses bases de données doivent démarrer sur un claquement de doigt > (et j'ai configuré CORRECTEMENT systemd pour éviter ça, un coup ça > passe, un coup ça casse !). Et c'est sans compter les renommages > d'interfaces réseau et tous les problèmes liés. Un truc a installer une Gentoo malgré que l'absence de systemD ne leur permettent pas de contrôler la théière et l'arrosage du jardin au boot ?
Re: Toujours des plantage Xorg
Daniel Caillibaud a écrit : > Le 18/09/20 à 19:15, BERTRAND Joël a écrit : >>> Une piste ? >> >> Aucune, mais ce n'est pas lié à la génération du processeur. > >> Le dual screen ne serait-il pas pour quelque chose dans le problème ? > > Peut-être, mais ça doit pas être la seule origine, si le dual screen ne > fonctionnait pas avec > xorg/wayland qqun s'en serait occupé. Pas sûr. Il y a des bugs conséquents qui traînent depuis au moins 2001 sur des cartes réseau massivement utilisées (des histoires de veilles et de réveils). Il existe aussi des bugs dans Mesa qui me pourrissent la vie depuis au moins 2017 (pas testé avant) et qui font que je vais devoir me payer une carte graphique AMD pour utiliser KiCAD sans avoir de vautrage du GPU Intel. > Le pb est surtout que les logs racontent pas grand chose… difficile de savoir > où creuser… Rien dans les logs. Mais le problème apparaît à chaque fois que la machine se met à swapper (c'est un poste diskless). La charge monte, bloque X, et ça me fait penser à un watchdog qui tue X parce qu'il trouve qu'il ne répond plus assez vite. Je n'ai jamais réussi à reproduire le problème sur une machine avec un seul écran (et sans swap). Je n'ai pas le temps de bissecter le problème. > En tout cas j'ai toujours pas mal de pb avec cette machine récente (wifi > notamment, y'a parfois > qu'un reboot hard pour récupérer du réseau car même si j'ai toujours la main > `systemct restart > network-manager.service` ne règle pas le pb et un reboot soft marche pas car > il veut pas > s'éteindre). Que veux-tu ? Linux devient de plus en plus n'importe quoi avec des couches non maîtrisées les unes au-dessus des autres. La plupart du temps, ça fonctionne à peu près. Mais lorsque tu es dans un cas non fonctionnel, c'est réellement un problème qui ne sera pas traité de sitôt. Personnellement, j'en suis à refuser de redémarrer des machines à distance tellement les motifs de plantage au boot sont nombreux sur des serveurs. J'ai même des machines (serveurs de bases de données) qui se VAUTRENT au démarrage parce que systemd considère que les grosses bases de données doivent démarrer sur un claquement de doigt (et j'ai configuré CORRECTEMENT systemd pour éviter ça, un coup ça passe, un coup ça casse !). Et c'est sans compter les renommages d'interfaces réseau et tous les problèmes liés. Bien cordialement, JKB
Re: Toujours des plantage Xorg
Le 18/09/20 à 19:15, BERTRAND Joël a écrit : > > Une piste ? > > Aucune, mais ce n'est pas lié à la génération du processeur. > Le dual screen ne serait-il pas pour quelque chose dans le problème ? Peut-être, mais ça doit pas être la seule origine, si le dual screen ne fonctionnait pas avec xorg/wayland qqun s'en serait occupé. Le pb est surtout que les logs racontent pas grand chose… difficile de savoir où creuser… En tout cas j'ai toujours pas mal de pb avec cette machine récente (wifi notamment, y'a parfois qu'un reboot hard pour récupérer du réseau car même si j'ai toujours la main `systemct restart network-manager.service` ne règle pas le pb et un reboot soft marche pas car il veut pas s'éteindre). -- Daniel Quand j'écoute trop Wagner, j'ai envie d'envahir la Pologne. Woody Allen
Re: Toujours des plantage Xorg
Bonsoir, > Une piste ? Aucune, mais ce n'est pas lié à la génération du processeur. Mon i7-4470 fait exactement la même chose. Tiens, chose amusante, je suis aussi en dual screen et, maintenant que tu me le fais remarquer, la machine que j'utilise avec un seul écran (mais avec une résolution supérieure, quelque chose comme 2600x1440) est remarquablement stable. Le dual screen ne serait-il pas pour quelque chose dans le problème ? JKB
Toujours des plantage Xorg
Bonjour, J'ai toujours des soucis de plantages Xorg, apparemment liés au driver i915 (j'ai pas de carte vidéo dédiée, j'utilise intel UHD du cpu, un i5 1035G1). J'avais essentiellement des crash avec mon IDE (jetbrains), et c'était visiblement lié à un bug du firmware intel sur les cpu 10e génération, cf https://youtrack.jetbrains.com/issue/JBR-2310 En modifiant les paramètres passés à la JVM (qui fait tourner l'IDE) j'ai réussi à réduire le nb de plantages mais pas à les supprimer. J'ai finalement upgradé manuellement mon firmware (et décrit la méthode sur https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/39, y'a même hmh, le mainteneur debian du paquet intel-microcode, qui a répondu en filant une méthode plus simple), ça a fonctionné qq jours mais c'est revenu :-/ C'est maintenant un peu différent, avant ça figeait tout d'un coup (plus de clavier ni souris) et après un moment m'affichait l'écran de login X. Maintenant le curseur de souris bouge, je peux parfois ouvrir une console avec alt+F1, mais le display X semble complètement figé (alt+tab ne fait rien, cliquer sur un autre bureau / fenêtre non plus). Visiblement c'est Xorg qui plante (et il est redémarré, ou pas…), et pas seulement en utilisant cet IDE. Les seules traces que j'ai sont dans le kern.log (rien dans ~/.xsession-errors.old) : Sep 16 15:34:20 dell kernel: [60673.586907] i915 :00:02.0: Resetting rcs0 for preemption time out Sep 16 15:34:20 dell kernel: [60673.586937] i915 :00:02.0: Xorg[22942] context reset due to GPU hang Sep 16 15:34:20 dell kernel: [60673.595929] i915 :00:02.0: GPU HANG: ecode 11:1:85db, in Xorg [22942] Sep 16 15:34:30 dell kernel: [60683.570791] i915 :00:02.0: Resetting rcs0 for preemption time out Sep 16 15:34:30 dell kernel: [60683.570806] i915 :00:02.0: Xorg[22942] context reset due to GPU hang Sep 16 15:34:30 dell kernel: [60683.579715] i915 :00:02.0: GPU HANG: ecode 11:1:8795bff9, in Xorg [22942] Sep 16 15:34:40 dell kernel: [60693.554873] i915 :00:02.0: Resetting rcs0 for preemption time out Sep 16 15:34:40 dell kernel: [60693.554889] i915 :00:02.0: Xorg[22942] context reset due to GPU hang Sep 16 15:34:40 dell kernel: [60693.563863] i915 :00:02.0: GPU HANG: ecode 11:1:8795bff9, in Xorg [22942] Sep 16 15:34:41 dell kernel: [60694.283394] broken atomic modeset userspace detected, disabling atomic Sep 16 15:34:46 dell kernel: [60699.802588] broken atomic modeset userspace detected, disabling atomic ici un plantage avec chromium Sep 18 14:21:57 dell kernel: [76555.872996] i915 :00:02.0: Resetting rcs0 for preemption time out Sep 18 14:21:57 dell kernel: [76555.873011] i915 :00:02.0: chromium[16299] context reset due to GPU hang Sep 18 14:21:57 dell kernel: [76555.73] i915 :00:02.0: GPU HANG: ecode 11:1:85db, in chromium [16299] Sep 18 14:22:23 dell kernel: [76581.765376] i915 :00:02.0: Resetting rcs0 for preemption time out Sep 18 14:22:23 dell kernel: [76581.765392] i915 :00:02.0: chromium[16299] context reset due to GPU hang Sep 18 14:22:23 dell kernel: [76581.787147] i915 :00:02.0: GPU HANG: ecode 11:1:86db, in chromium [16299] Sep 18 14:25:14 dell kernel: [76752.181102] broken atomic modeset userspace detected, disabling atomic Sur un conseil j'ai passé l'antialiasing en niveau de gris (plutôt que le choix par défaut), mais ça change rien. Une piste ? le contexte : dell inspiron 3793 cpu intel i5-1035G1 debian buster kernel 5.7.0-0.bpo.2-amd64 intel-microcode rev 0x96 lightdm 1.26.0-4 cinnamon 3.8.8-1 xserver-xorg 1:7.7+19 xwayland 2:1.20.4-1+deb10u1 dual screen (1920x1080 ×2) -- Daniel Les allemands sortent la première voiture qui se boit après manger : l'Audi cointreau. Les nuls
Re: plantages Xorg
Le 20/05/20 à 16:40, Daniel Caillibaud a écrit : > J'y ai crû, pu bosser normalement toute la matinée et le début d'aprèm, mais > ça a planté de > nouveau, avec le même message > > May 20 15:40:45 dell kernel: [23928.458005] i915 :00:02.0: GPU HANG: ecode > 11:1:0x86dd, in Xorg [2319], hang on rcs0 May 20 15:40:45 dell kernel: > [23928.459084] > i915 :00:02.0: Resetting rcs0 for hang on rcs0 May 20 15:40:53 dell > kernel: > [23936.451296] i915 :00:02.0: Resetting rcs0 for hang on rcs0 > En attendant je vais tester le noyau 5.5.0 de buster-backports, car pour > certains le passage > en 5.5 a réglé le pb (mais 5.5.0 est p'tet pas assez récent), et si ça suffit > pas j'essaierai > de compiler un 5.6.14 depuis les sources. Pour info, j'ai installé manuellement le kernel 5.6 de testing (récupéré sur https://packages.debian.org/bullseye/amd64/linux-image-5.6.0-1-amd64/download) et depuis ça ne plante plus… J'ai de temps en temps le wifi qui saute (ma box ping plus, je dois déconnecter / reconnecter le wifi ou bien faire un `systemctl restart network-manager.service`), mais je suis pas sûr que ce soit lié. J'ai mis le 5.6 car le 5.5 est passé en EOL[1] (et aussi car j'étais resté sur le fait que les versions stables du kernel étaient les versions avec un n° mineur pair, mais c'est plus d'actualité depuis 3.x) [1] End Of Life, d'après https://en.wikipedia.org/wiki/Linux_kernel_version_history -- Daniel Dieu a sagement agi en plaçant la naissance avant la mort; sans cela, que saurait-on de la vie ? Alphonse Allais
Re: plantages Xorg
Le 20/05/20 à 00:33, Daniel Caillibaud a écrit : > Le 19/05/20 à 19:01, Étienne Mollier a écrit : > > Bonjour, à tout hasard, est-ce qu'inclure ces firmware manquants > > depuis l'amont ferait une différence ? > > > > https://lists.debian.org/debian-user-french/2020/05/msg00207.html > > > > Je me permet d'insister > > Merci pour la piqûre de rappel, j'avais zappé ça dans cette réponse à un fil > précédent, ça > devrait bien aider (y'a une version toute fraîche linux-firmware-20200519). > > Je verrai demain si c'est plus stable. J'y ai crû, pu bosser normalement toute la matinée et le début d'aprèm, mais ça a planté de nouveau, avec le même message May 20 15:40:45 dell kernel: [23928.458005] i915 :00:02.0: GPU HANG: ecode 11:1:0x86dd, in Xorg [2319], hang on rcs0 May 20 15:40:45 dell kernel: [23928.459084] i915 :00:02.0: Resetting rcs0 for hang on rcs0 May 20 15:40:53 dell kernel: [23936.451296] i915 :00:02.0: Resetting rcs0 for hang on rcs0 Je suis pas le seul à avoir le pb, pas mal d'autres (archLinux & ubuntu), dont celui-là qui ressemble à mon pb (ça plante quand je bosse sur mon IDE, mais vu que c'est mon activité principale c'est pas forcément très significatif) https://youtrack.jetbrains.com/issue/JBR-2265 Y'a moyen de désactiver des trucs pour voir si ça plante moins ? (je pense à l'accélération matérielle, vu ce que je fais je peux m'en passer, mais je sais plus du tout où on peut préciser ça, j'ai même pas trouvé de xorg.conf) En attendant je vais tester le noyau 5.5.0 de buster-backports, car pour certains le passage en 5.5 a réglé le pb (mais 5.5.0 est p'tet pas assez récent), et si ça suffit pas j'essaierai de compiler un 5.6.14 depuis les sources. -- Daniel C'est pas parce qu'on a rien à dire qu'il faut fermer sa gueule. Michel Audiard
Re: plantages Xorg
Une piste peut être : Un lien : https://gitlab.freedesktop.org/xorg/xserver/issues/102 il semble qu'il faut mettre un paramètre danx xorg.conf Philippe Merlin Le mardi 19 mai 2020, 13:16:47 CEST Daniel Caillibaud a écrit : > Salut, > > Suite de mes déboires avec mon nouveau dell 3793, xorg plante violemment > sans que j'ai isolé une cause en particulier (j'ai cru que c'était plus > souvent au retour de veille mais pas spécialement, il vient de replanter > après un boot normal et 2h d'utilisation). > > Dans kern.log je trouve > > May 19 12:28:04 dell kernel: [13786.197377] i915 0000:00:02.0: GPU HANG: > ecode 11:1:0x86dd, in Xorg [2149], hang on rcs0 May 19 12:28:04 dell > kernel: [13786.198452] i915 :00:02.0: Resetting rcs0 for hang on rcs0 > May 19 12:28:12 dell kernel: [13794.191513] i915 :00:02.0: Resetting > rcs0 for hang on rcs0 May 19 12:28:20 dell kernel: [13802.191705] i915 > :00:02.0: Resetting rcs0 for hang on rcs0 > > et dans Xorg.0.log > [ 13794.966] (EE) client bug: timer event11 debounce short: offset negative > (-0ms) > > Y'a aussi du > [19.430] (EE) modeset(0): [DRI2] No driver mapping found for PCI device > 0x8086 / 0x8a56 [19.430] (EE) modeset(0): Failed to initialize the DRI2 > extension. à chaque démarrage X > > J'ai tenté de réinstaller les firmware non-free pour voir si ça changeait > qqchose > > firmware-linux-nonfree=20190717-2~bpo10+1 > firmware-amd-graphics=20190717-2~bpo10+1 > firmware-misc-nonfree=20190717-2~bpo10+1 > > mais à part de m'ajouter ces messages au build de l'initrd > > W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module > r8169 W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_07.bin > for module i915 W: Possible missing firmware > /lib/firmware/i915/tgl_dmc_ver2_04.bin for module i915 W: Possible missing > firmware /lib/firmware/i915/bxt_huc_ver01_8_2893.bin for module i915 > > ça plante ni plus ni moins… > > J'ai essayé gdm3 à la place de lightdm, idem… > > Dans /vl/daemon.log je trouve > > May 19 12:28:20 dell bluetoothd[1114]: Endpoint unregistered: sender=:1.295 > path=/MediaEndpoint/A2DPSource May 19 12:28:20 dell > at-spi-bus-launcher[2219]: XIO: fatal IO error 11 (Resource temporarily > unavailable) on X server ":0" May 19 12:28:20 dell > at-spi-bus-launcher[2219]: after 24688 requests (24688 known > processed) with 0 events remaining. May 19 12:28:20 dell > gnome-terminal-server[3069]: > [3223:3223:0519/122820.029461:ERROR:chrome_browser_main_extra_parts_x11.cc( > 62)] X IO error received (X server probably went away) May 19 12:28:20 dell > pulseaudio[2273]: XIO: fatal IO error 11 (Ressource temporairement non > disponible) on X server ":0" May 19 12:28:20 dell pulseaudio[2273]: > after 19 requests (19 known processed) with 0 events remaining. May 19 > 12:28:20 dell bluetoothd[1114]: Endpoint unregistered: sender=:1.295 > path=/MediaEndpoint/A2DPSink May 19 12:28:20 dell > gnome-terminal-server[3069]: > [3261:3261:0519/122820.029507:ERROR:x11_util.cc(109)] X IO error received > (X server probably went away) > > Ce serait le bluetooth qui plante X ? Je vais le virer pour voir, mais > kern.log parle de pb GPU 16s plus tôt, je suppose que c'est donc plutôt un > pb de driver vidéo. > > Le chipset vidéo est l'intel UHD 620 intégré au i5-1035G1, j'utilise > cinnamon… > > Une piste ? > > Merci à ceux qui auraient une idée et voudront bien la partager ;-)
Re: plantages Xorg
Le 19/05/20 à 19:01, Étienne Mollier a écrit : > Bonjour, à tout hasard, est-ce qu'inclure ces firmware manquants > depuis l'amont ferait une différence ? > > https://lists.debian.org/debian-user-french/2020/05/msg00207.html > > Je me permet d'insister Merci pour la piqûre de rappel, j'avais zappé ça dans cette réponse à un fil précédent, ça devrait bien aider (y'a une version toute fraîche linux-firmware-20200519). Je verrai demain si c'est plus stable. -- Daniel Le génie consiste à voir ce que tout le monde a vu et à penser ce que personne n'a pensé.
Re: plantages Xorg
Daniel Caillibaud, on 2020-05-19 13:16:47 +0200: > Dans kern.log je trouve > > May 19 12:28:04 dell kernel: [13786.197377] i915 :00:02.0: GPU HANG: > ecode 11:1:0x86dffffd, in Xorg [2149], hang on rcs0 > May 19 12:28:04 dell kernel: [13786.198452] i915 :00:02.0: Resetting rcs0 > for hang on rcs0 > May 19 12:28:12 dell kernel: [13794.191513] i915 :00:02.0: Resetting rcs0 > for hang on rcs0 > May 19 12:28:20 dell kernel: [13802.191705] i915 :00:02.0: Resetting rcs0 > for hang on rcs0 > > et dans Xorg.0.log > [ 13794.966] (EE) client bug: timer event11 debounce short: offset negative > (-0ms) > > Y'a aussi du > [19.430] (EE) modeset(0): [DRI2] No driver mapping found for PCI device > 0x8086 / 0x8a56 > [19.430] (EE) modeset(0): Failed to initialize the DRI2 extension. > à chaque démarrage X > > J'ai tenté de réinstaller les firmware non-free pour voir si ça changeait > qqchose > > firmware-linux-nonfree=20190717-2~bpo10+1 > firmware-amd-graphics=20190717-2~bpo10+1 > firmware-misc-nonfree=20190717-2~bpo10+1 > > mais à part de m'ajouter ces messages au build de l'initrd > > W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module > r8169 > W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_07.bin for > module i915 > W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_04.bin for > module i915 > W: Possible missing firmware /lib/firmware/i915/bxt_huc_ver01_8_2893.bin for > module i915 Bonjour, à tout hasard, est-ce qu'inclure ces firmware manquants depuis l'amont ferait une différence ? https://lists.debian.org/debian-user-french/2020/05/msg00207.html Je me permet d'insister, car je crois que ce paramètre peut avoir une influence non négligeable sur la stabilité du serveur d'affichage. Bien sûr, si vous avez déjà essayé... :) Bonne soirée, -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d Help find cures against the Covid-19 ! Give CPU cycles: * Rosetta@home: https://boinc.bakerlab.org/rosetta/ * Folding@home: https://foldingathome.org/ signature.asc Description: PGP signature
Re: plantages Xorg
Salut, Une idée As tu aussi chargé le paquet intel-microcode? Philippe Merlin Le mardi 19 mai 2020, 13:16:47 CEST Daniel Caillibaud a écrit : > Salut, > > Suite de mes déboires avec mon nouveau dell 3793, xorg plante violemment > sans que j'ai isolé une cause en particulier (j'ai cru que c'était plus > souvent au retour de veille mais pas spécialement, il vient de replanter > après un boot normal et 2h d'utilisation). > > Dans kern.log je trouve > > May 19 12:28:04 dell kernel: [13786.197377] i915 0000:00:02.0: GPU HANG: > ecode 11:1:0x86dd, in Xorg [2149], hang on rcs0 May 19 12:28:04 dell > kernel: [13786.198452] i915 :00:02.0: Resetting rcs0 for hang on rcs0 > May 19 12:28:12 dell kernel: [13794.191513] i915 :00:02.0: Resetting > rcs0 for hang on rcs0 May 19 12:28:20 dell kernel: [13802.191705] i915 > :00:02.0: Resetting rcs0 for hang on rcs0 > > et dans Xorg.0.log > [ 13794.966] (EE) client bug: timer event11 debounce short: offset negative > (-0ms) > > Y'a aussi du > [19.430] (EE) modeset(0): [DRI2] No driver mapping found for PCI device > 0x8086 / 0x8a56 [19.430] (EE) modeset(0): Failed to initialize the DRI2 > extension. à chaque démarrage X > > J'ai tenté de réinstaller les firmware non-free pour voir si ça changeait > qqchose > > firmware-linux-nonfree=20190717-2~bpo10+1 > firmware-amd-graphics=20190717-2~bpo10+1 > firmware-misc-nonfree=20190717-2~bpo10+1 > > mais à part de m'ajouter ces messages au build de l'initrd > > W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module > r8169 W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_07.bin > for module i915 W: Possible missing firmware > /lib/firmware/i915/tgl_dmc_ver2_04.bin for module i915 W: Possible missing > firmware /lib/firmware/i915/bxt_huc_ver01_8_2893.bin for module i915 > > ça plante ni plus ni moins… > > J'ai essayé gdm3 à la place de lightdm, idem… > > Dans /vl/daemon.log je trouve > > May 19 12:28:20 dell bluetoothd[1114]: Endpoint unregistered: sender=:1.295 > path=/MediaEndpoint/A2DPSource May 19 12:28:20 dell > at-spi-bus-launcher[2219]: XIO: fatal IO error 11 (Resource temporarily > unavailable) on X server ":0" May 19 12:28:20 dell > at-spi-bus-launcher[2219]: after 24688 requests (24688 known > processed) with 0 events remaining. May 19 12:28:20 dell > gnome-terminal-server[3069]: > [3223:3223:0519/122820.029461:ERROR:chrome_browser_main_extra_parts_x11.cc( > 62)] X IO error received (X server probably went away) May 19 12:28:20 dell > pulseaudio[2273]: XIO: fatal IO error 11 (Ressource temporairement non > disponible) on X server ":0" May 19 12:28:20 dell pulseaudio[2273]: > after 19 requests (19 known processed) with 0 events remaining. May 19 > 12:28:20 dell bluetoothd[1114]: Endpoint unregistered: sender=:1.295 > path=/MediaEndpoint/A2DPSink May 19 12:28:20 dell > gnome-terminal-server[3069]: > [3261:3261:0519/122820.029507:ERROR:x11_util.cc(109)] X IO error received > (X server probably went away) > > Ce serait le bluetooth qui plante X ? Je vais le virer pour voir, mais > kern.log parle de pb GPU 16s plus tôt, je suppose que c'est donc plutôt un > pb de driver vidéo. > > Le chipset vidéo est l'intel UHD 620 intégré au i5-1035G1, j'utilise > cinnamon… > > Une piste ? > > Merci à ceux qui auraient une idée et voudront bien la partager ;-)
Re: plantages Xorg
Le 19/05/20 à 14:03, MERLIN Philippe a écrit : > Salut, > Une idée As tu aussi chargé le paquet intel-microcode? Oui, dans buster/non-free (il est pas dans les backport), j'aurais intérêt à tester la version de https://packages.debian.org/bullseye/intel-microcode ? En prenant alors aussi initramfs-tools dans bullseye histoire d'être raccord avec le noyau ? J'avais pas trop envie de jouer avec du pinning, mais si y'a pas d'autre solution… -- Daniel On ne peut pas juger quelqu'un à ses fréquentations ; ne perdons pas de vue que Judas avait des amis irréprochables. Tristan Bernard
Re : plantages Xorg
Le 19/05/2020 13:16:47, Daniel Caillibaud a écrit : > Ce serait le bluetooth qui plante X ? Je vais le virer pour voir, mais > kern.log parle de pb GPU 16s plus tôt, > je suppose que c'est donc plutôt un pb de driver vidéo. > Le chipset vidéo est l'intel UHD 620 intégré au i5-1035G1, j'utilise > cinnamon… > Une piste ? > Merci à ceux qui auraient une idée et voudront bien la partager ;-) Ça peut être plein de choses : un pilote foireux, une carte graphique boguée, une alimentation qui a du mal à suivre ou qui perd un condensateur, un composant qui chauffe… Sur mon vieux PC (acheté fin 2011), je sais que si je le sollicite trop, ça chauffe et ça finit par planter. Même Doom le fait planter. Le précédent lâchait quand je jouais à Quake (des condensateurs de l’alimentation gonflaient). Regarde les capteurs de température pour voir si ça vient de là ou non. Peux-tu t’y connecter via ssh ou non ? nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
plantages Xorg
Salut, Suite de mes déboires avec mon nouveau dell 3793, xorg plante violemment sans que j'ai isolé une cause en particulier (j'ai cru que c'était plus souvent au retour de veille mais pas spécialement, il vient de replanter après un boot normal et 2h d'utilisation). Dans kern.log je trouve May 19 12:28:04 dell kernel: [13786.197377] i915 :00:02.0: GPU HANG: ecode 11:1:0x86dd, in Xorg [2149], hang on rcs0 May 19 12:28:04 dell kernel: [13786.198452] i915 :00:02.0: Resetting rcs0 for hang on rcs0 May 19 12:28:12 dell kernel: [13794.191513] i915 :00:02.0: Resetting rcs0 for hang on rcs0 May 19 12:28:20 dell kernel: [13802.191705] i915 :00:02.0: Resetting rcs0 for hang on rcs0 et dans Xorg.0.log [ 13794.966] (EE) client bug: timer event11 debounce short: offset negative (-0ms) Y'a aussi du [19.430] (EE) modeset(0): [DRI2] No driver mapping found for PCI device 0x8086 / 0x8a56 [19.430] (EE) modeset(0): Failed to initialize the DRI2 extension. à chaque démarrage X J'ai tenté de réinstaller les firmware non-free pour voir si ça changeait qqchose firmware-linux-nonfree=20190717-2~bpo10+1 firmware-amd-graphics=20190717-2~bpo10+1 firmware-misc-nonfree=20190717-2~bpo10+1 mais à part de m'ajouter ces messages au build de l'initrd W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module r8169 W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_07.bin for module i915 W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_04.bin for module i915 W: Possible missing firmware /lib/firmware/i915/bxt_huc_ver01_8_2893.bin for module i915 ça plante ni plus ni moins… J'ai essayé gdm3 à la place de lightdm, idem… Dans /vl/daemon.log je trouve May 19 12:28:20 dell bluetoothd[1114]: Endpoint unregistered: sender=:1.295 path=/MediaEndpoint/A2DPSource May 19 12:28:20 dell at-spi-bus-launcher[2219]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" May 19 12:28:20 dell at-spi-bus-launcher[2219]: after 24688 requests (24688 known processed) with 0 events remaining. May 19 12:28:20 dell gnome-terminal-server[3069]: [3223:3223:0519/122820.029461:ERROR:chrome_browser_main_extra_parts_x11.cc(62)] X IO error received (X server probably went away) May 19 12:28:20 dell pulseaudio[2273]: XIO: fatal IO error 11 (Ressource temporairement non disponible) on X server ":0" May 19 12:28:20 dell pulseaudio[2273]: after 19 requests (19 known processed) with 0 events remaining. May 19 12:28:20 dell bluetoothd[1114]: Endpoint unregistered: sender=:1.295 path=/MediaEndpoint/A2DPSink May 19 12:28:20 dell gnome-terminal-server[3069]: [3261:3261:0519/122820.029507:ERROR:x11_util.cc(109)] X IO error received (X server probably went away) Ce serait le bluetooth qui plante X ? Je vais le virer pour voir, mais kern.log parle de pb GPU 16s plus tôt, je suppose que c'est donc plutôt un pb de driver vidéo. Le chipset vidéo est l'intel UHD 620 intégré au i5-1035G1, j'utilise cinnamon… Une piste ? Merci à ceux qui auraient une idée et voudront bien la partager ;-) -- Daniel Quand j'écoute trop Wagner, j'ai envie d'envahir la Pologne. Woody Allen
Re: Xorg non fonctionnel
Le 17/02/2020 à 18:40, Nicolas PÉCHON a écrit : Malheureusement, la ligne ne comprend que le paramètre `quiet` Bonjour, desormais le parametre pour regler la resolution au demarrage est GRUB_GFXMODE, et pour qu'il y ait un "framebuffer", il vaut que celui-ci en demande une qui soit de type "graphique". Mais de toutes facons, un X utilisant "framebuffer" serait probablement inutilisable, non? On peut s'amuser par exemple a lancer elinks2 en console framebuffer... ca ressemble a m$ Dosshell pour ceux qui ont connu... -- Cordialement, Stephane Ascoet
Re: Xorg non fonctionnel
Bonsoir Avec les versions modernes de Xorg, iln'y a généralement plus besoin d'avoir de fichier Xorg.conf. tout est détecté automatiquement (en principe, et dans les cas standards / courants). En cherchant comment activer / désactiver le framebuffer au niveau des paramètres du noyau, je suis tombé sur cette question, qui a un contexte assez proche. (En anglais et de 2012...) https://unix.stackexchange.com/questions/33596/no-framebuffer-device-how-to-enable-it Selon ce que j'y lis, j'essaierais de charger le module vesafb ou uvesafb puis tenter de charger l'environnement graphique. (En root) modprobe vesafb modprobe uvesafb # si vesafb a échoué startx # avec une autre console pour éviter de lancer X en root Si ça marche, alors il faudrait voir si le module est blacklisté. Quel est le chipset de l'ordinateur (lspci devrait aider à le déterminer) ? Le 17 février 2020 18:42:35 GMT+01:00, "Nicolas PÉCHON" a écrit : > > > >> >>En complément que la question de Nicolas: Est-ce qu'il y a un fichier >>/etc/X11/xorg.conf ? Si oui quel est son contenu ? >> > >En fait, pas de xorg.conf > >-- >Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser >ma brièveté. -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: Xorg non fonctionnel
> >En complément que la question de Nicolas: Est-ce qu'il y a un fichier >/etc/X11/xorg.conf ? Si oui quel est son contenu ? > En fait, pas de xorg.conf -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: Xorg non fonctionnel
Le 17 février 2020 09:25:43 GMT+01:00, >Peut-être y a-t-il un paramètre vga=quelquechose dans le fichier >/etc/default/grub (à la ligne GRUB_CMDLINE_LINUX_DEFAULT ou >GRUB_CMDLINE_LINUX). Avec le compte root (ou en mode sudo), édite le >fichier, vire le paramètre, puis lance la commande update-grub et >redémarre le PC. Il est fort possible que X démarre normalement. Malheureusement, la ligne ne comprend que le paramètre `quiet` -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: Re : Xorg non fonctionnel
Le 16 février 2020 20:19:45 GMT+01:00, Dethegeek a écrit : >Bonjour > Bonjour et merci de votre aide > >Donc il serait intéressant de savoir si il existe un Xorg.conf, en plus >de connaître la carte graphique effectivement installée. > Il n'y avait pas de xorg.conf. J'en ai généré un. Toutefois, cela n'y a rien fait. -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: Xorg non fonctionnel
Le dimanche 16 février 2020 19:20:03 UTC+1, zut...@laposte.net a écrit : > Bonjour, > > > > j'ai un soucis avec Xorg qui refuse de démarrer. > > Si quelqu'un pouvait me donner une piste. > Je précise que je suis sous une DEBIAN stable. > L'ordinateur avait une ubuntu dessus. Mais, mon fils préférant debian... > > voici mon fichier de log(Xorg.0.log): [...] > [ 1227.684] (EE) Unable to find a valid framebuffer device [...] Peut-être y a-t-il un paramètre vga=quelquechose dans le fichier /etc/default/grub (à la ligne GRUB_CMDLINE_LINUX_DEFAULT ou GRUB_CMDLINE_LINUX). Avec le compte root (ou en mode sudo), édite le fichier, vire le paramètre, puis lance la commande update-grub et redémarre le PC. Il est fort possible que X démarre normalement.
Re: Re : Xorg non fonctionnel
> >Tu as quelle carte graphique ? > >nicolas patrois : pts noir asocial Bonjour, Merci de votre aide. Voici ce que je trouve: #lshw -c video *-display NON-RÉCLAMÉ description: VGA compatible controller produit: Intel Corporation fabriquant: Intel Corporation identifiant matériel: 2 information bus: pci@:00:02.0 version: 02 bits: 64 bits horloge: 33MHz fonctionnalités: pciexpress msi pm vga_controller bus_master cap_list configuration: latency=0 ressources: mémoire:b200-b2ff mémoire:a000-afff portE/S:5000(taille=64) mémoire:c-d -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: Re : Xorg non fonctionnel
Bonjour En principe le log devrait donner des infos sur la carte graphique, ainsi que des infos sur les modes d'affichage disponibles. Là il n'y a apparemment rien de tout cela et je note la possible utilisation du pilote VESA (totalement obsolète, et n'utilisant aucune spécificité de la carte graphique installée). En gros un retour aux spécifications des années 1990/2000. Donc il serait intéressant de savoir si il existe un Xorg.conf, en plus de connaître la carte graphique effectivement installée. Le 16 février 2020 19:25:44 GMT+01:00, nicolas.patr...@gmail.com a écrit : >Le 16/02/2020 19:11:25, zut...@laposte.net a écrit : > >> Bonjour, > >> j'ai un soucis avec Xorg qui refuse de démarrer. > >> Si quelqu'un pouvait me donner une piste. >> Je précise que je suis sous une DEBIAN stable. >> L'ordinateur avait une ubuntu dessus. Mais, mon fils préférant >> debian... > >Tu as quelle carte graphique ? > >nicolas patrois : pts noir asocial >-- >RÉALISME > >M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des >humains ? Un cerveau plus gros ? >P : Non... Une carte bleue suffirait... -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: Xorg non fonctionnel
Le dimanche 16 février 2020 à 19:25 +0100, nicolas.patr...@gmail.com a écrit : > Le 16/02/2020 19:11:25, zut...@laposte.net a écrit : > > > Bonjour, > > j'ai un soucis avec Xorg qui refuse de démarrer. > > Si quelqu'un pouvait me donner une piste. > > Je précise que je suis sous une DEBIAN stable. > > L'ordinateur avait une ubuntu dessus. Mais, mon fils préférant > > debian... > > Tu as quelle carte graphique ? > > nicolas patrois : pts noir asocial En complément que la question de Nicolas: Est-ce qu'il y a un fichier /etc/X11/xorg.conf ? Si oui quel est son contenu ? Gaëtan signature.asc Description: This is a digitally signed message part
Xorg non fonctionnel
Bonjour, j'ai un soucis avec Xorg qui refuse de démarrer. Si quelqu'un pouvait me donner une piste. Je précise que je suis sous une DEBIAN stable. L'ordinateur avait une ubuntu dessus. Mais, mon fils préférant debian... voici mon fichier de log(Xorg.0.log): [ 1227.656] X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 [ 1227.662] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian [ 1227.664] Current Operating System: Linux erwan-portable 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 [ 1227.664] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-8-amd64 root=/dev/mapper/E-root ro quiet [ 1227.667] Build Date: 05 March 2019 08:11:12PM [ 1227.669] xorg-server 2:1.20.4-1 ( https://www.debian.org/support ) [ 1227.670] Current version of pixman: 0.36.0 [ 1227.672] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 1227.672] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 1227.677] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Feb 15 17:28:05 2020 [ 1227.678] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 1227.678] (==) No Layout section. Using the first Screen section. [ 1227.678] (==) No screen section available. Using defaults. [ 1227.678] (**) |-->Screen "Default Screen Section" (0) [ 1227.678] (**) | |-->Monitor "" [ 1227.678] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 1227.678] (==) Automatically adding devices [ 1227.678] (==) Automatically enabling devices [ 1227.678] (==) Automatically adding GPU devices [ 1227.678] (==) Max clients allowed: 256, resource mask: 0x1f [ 1227.678] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 1227.678] Entry deleted from font path. [ 1227.678] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 1227.678] (==) ModulePath set to "/usr/lib/xorg/modules" [ 1227.678] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 1227.678] (II) Loader magic: 0x5556f71e2e20 [ 1227.678] (II) Module ABI versions: [ 1227.678] X.Org ANSI C Emulation: 0.4 [ 1227.678] X.Org Video Driver: 24.0 [ 1227.678] X.Org XInput driver : 24.1 [ 1227.678] X.Org Server Extension : 10.0 [ 1227.679] (++) using VT number 2 [ 1227.681] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_32 [ 1227.682] (--) PCI:*(0@0:2:0) 8086:9b41:1558:40c1 rev 2, Mem @ 0xb200/16777216, 0xa000/268435456, I/O @ 0x5000/64, BIOS @ 0x/131072 [ 1227.682] (II) LoadModule: "glx" [ 1227.682] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 1227.683] (II) Module glx: vendor="X.Org Foundation" [ 1227.683] compiled for 1.20.4, module version = 1.0.0 [ 1227.683] ABI class: X.Org Server Extension, version 10.0 [ 1227.683] (==) Matched modesetting as autoconfigured driver 0 [ 1227.683] (==) Matched fbdev as autoconfigured driver 1 [ 1227.683] (==) Matched vesa as autoconfigured driver 2 [ 1227.683] (==) Assigned the driver to the xf86ConfigLayout [ 1227.683] (II) LoadModule: "modesetting" [ 1227.683] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [ 1227.683] (II) Module modesetting: vendor="X.Org Foundation" [ 1227.683] compiled for 1.20.4, module version = 1.20.4 [ 1227.683] Module class: X.Org Video Driver [ 1227.683] ABI class: X.Org Video Driver, version 24.0 [ 1227.683] (II) LoadModule: "fbdev" [ 1227.683] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [ 1227.683] (II) Module fbdev: vendor="X.Org Foundation" [ 1227.683] compiled for 1.20.0, module version = 0.5.0 [ 1227.683] Module class: X.Org Video Driver [ 1227.683] ABI class: X.Org Video Driver, version 24.0 [ 1227.683] (II) LoadModule: "vesa" [ 1227.683] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so [ 1227.683] (II) Module vesa: vendor="X.Org Foundation" [ 1227.683] compiled for 1.20.1, module version = 2.4.0 [ 1227.683] Module class: X.Org Video Driver [ 1227.683] ABI class: X.Org Video Driver, version 24.0 [ 1227.683] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 1227.683] (II) FBDEV: driver for framebuffer: fbdev [ 1227.684] (II) VESA: driver for VESA chipsets: vesa [ 1227.684] (EE) open /dev/dri/card0: No such file or directory [ 1227.684] (WW) Falling back to old probe method for modesetting [ 1227.684] (EE) open /dev/dri/card0: No
Re : Xorg non fonctionnel
Le 16/02/2020 19:11:25, zut...@laposte.net a écrit : > Bonjour, > j'ai un soucis avec Xorg qui refuse de démarrer. > Si quelqu'un pouvait me donner une piste. > Je précise que je suis sous une DEBIAN stable. > L'ordinateur avait une ubuntu dessus. Mais, mon fils préférant > debian... Tu as quelle carte graphique ? nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
Xorg non fonctionnel
Bonjour, j'ai un soucis avec Xorg qui refuse de démarrer. Si quelqu'un pouvait me donner une piste. Je précise que je suis sous une DEBIAN stable. L'ordinateur avait une ubuntu dessus. Mais, mon fils préférant debian... voici mon fichier de log(Xorg.0.log): [ 1227.656] X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 [ 1227.662] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian [ 1227.664] Current Operating System: Linux erwan-portable 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 [ 1227.664] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-8-amd64 root=/dev/mapper/E-root ro quiet [ 1227.667] Build Date: 05 March 2019 08:11:12PM [ 1227.669] xorg-server 2:1.20.4-1 ( https://www.debian.org/support ) [ 1227.670] Current version of pixman: 0.36.0 [ 1227.672] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 1227.672] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 1227.677] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Feb 15 17:28:05 2020 [ 1227.678] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 1227.678] (==) No Layout section. Using the first Screen section. [ 1227.678] (==) No screen section available. Using defaults. [ 1227.678] (**) |-->Screen "Default Screen Section" (0) [ 1227.678] (**) | |-->Monitor "" [ 1227.678] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 1227.678] (==) Automatically adding devices [ 1227.678] (==) Automatically enabling devices [ 1227.678] (==) Automatically adding GPU devices [ 1227.678] (==) Max clients allowed: 256, resource mask: 0x1f [ 1227.678] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 1227.678] Entry deleted from font path. [ 1227.678] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 1227.678] (==) ModulePath set to "/usr/lib/xorg/modules" [ 1227.678] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 1227.678] (II) Loader magic: 0x5556f71e2e20 [ 1227.678] (II) Module ABI versions: [ 1227.678] X.Org ANSI C Emulation: 0.4 [ 1227.678] X.Org Video Driver: 24.0 [ 1227.678] X.Org XInput driver : 24.1 [ 1227.678] X.Org Server Extension : 10.0 [ 1227.679] (++) using VT number 2 [ 1227.681] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_32 [ 1227.682] (--) PCI:*(0@0:2:0) 8086:9b41:1558:40c1 rev 2, Mem @ 0xb200/16777216, 0xa000/268435456, I/O @ 0x5000/64, BIOS @ 0x/131072 [ 1227.682] (II) LoadModule: "glx" [ 1227.682] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 1227.683] (II) Module glx: vendor="X.Org Foundation" [ 1227.683] compiled for 1.20.4, module version = 1.0.0 [ 1227.683] ABI class: X.Org Server Extension, version 10.0 [ 1227.683] (==) Matched modesetting as autoconfigured driver 0 [ 1227.683] (==) Matched fbdev as autoconfigured driver 1 [ 1227.683] (==) Matched vesa as autoconfigured driver 2 [ 1227.683] (==) Assigned the driver to the xf86ConfigLayout [ 1227.683] (II) LoadModule: "modesetting" [ 1227.683] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [ 1227.683] (II) Module modesetting: vendor="X.Org Foundation" [ 1227.683] compiled for 1.20.4, module version = 1.20.4 [ 1227.683] Module class: X.Org Video Driver [ 1227.683] ABI class: X.Org Video Driver, version 24.0 [ 1227.683] (II) LoadModule: "fbdev" [ 1227.683] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [ 1227.683] (II) Module fbdev: vendor="X.Org Foundation" [ 1227.683] compiled for 1.20.0, module version = 0.5.0 [ 1227.683] Module class: X.Org Video Driver [ 1227.683] ABI class: X.Org Video Driver, version 24.0 [ 1227.683] (II) LoadModule: "vesa" [ 1227.683] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so [ 1227.683] (II) Module vesa: vendor="X.Org Foundation" [ 1227.683] compiled for 1.20.1, module version = 2.4.0 [ 1227.683] Module class: X.Org Video Driver [ 1227.683] ABI class: X.Org Video Driver, version 24.0 [ 1227.683] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 1227.683] (II) FBDEV: driver for framebuffer: fbdev [ 1227.684] (II) VESA: driver for VESA chipsets: vesa [ 1227.684] (EE) open /dev/dri/card0: No such file or directory [ 1227.684] (WW) Falling back to old probe method for modesetting [ 1227.684] (EE) open /dev/
Re: Xorg en "dual-head dual-graphics card AMD/ATI 570 + 6450"
On 7/25/19 12:49 PM, Basile Starynkevitch wrote: On 7/18/19 2:18 AM, Basile Starynkevitch wrote: Bonsoir, (ce message est volontairement en HTML) Je suis sous Debian/Sid sur mon PC rimski, avec une carte mère haut de gamme et processeur AMD 2970WX, chipset X399 et 64Go de RAM et une capacité disque (aussi bien SSD que rotatifs) à faire des envieux -des téraoctets! Il a plusieurs PCs à la maison, mais ils sont tous sous Linux. Ma tendre épouse m'a offert récemment -pour mes 60 ans- un Samsung S34J550WQU <https://www.materiel.net/produit/201901110070.html> qui fonctionne isolément sans souci avec une Gigabyte Geforce GTX Nvidia 1050TI installé dans son PC à elle, sous Ubuntu 18.04, hermes (et à peu près aussi bien avec le pilote nouveau qu'avec le pilote propriétaire Nvidia; les différences étaient des problèmes de performance ou de lignes parasites à l'écran, sans importance ici). Ce Samsung S34J550WQU (très lourd à transporter!) a remplacé moralement mon précédent écran LG Flatron E2250V <https://www.lg.com/fr/moniteurs/lg-E2250V-PN-moniteur-lcd-led>. J'ai finalement échangé une des deux cartes graphiques de rimski avec celle dans le PC de mon épouse. J'ai donc maintenant les deux cartes graphiques suivantes % lspci|grep VGA 0b:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480] (rev ef) 42:00.0 VGA compatible controller: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] (rev a1) et ça fonctionne avec le xorg.conf ci-dessous. # fichier xorg.conf.rimski Section "ServerLayout" Identifier "X.org Multihead Basile patched" Screen 0 "BasileBigScreen" 0 0 Screen 1 "BasileSmallScreen" LeftOf "BasileBigScreen" InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" Option "Xinerama" 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" # Load "vnc" Load "radeon" 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 "BasileBigMonitor" VendorName "Samsung" ModelName "S34J550" EndSection Section "Monitor" Identifier "BasileSmallMonitor" VendorName "LG" ModelName "Flatron E2250V" EndSection Section "Device" Identifier "BasileAMD570Card" Driver "amdgpu" ## the BusID should be in decimal format ! Was 0b in hexa BusID "PCI:11:0:0" EndSection Section "Device" Identifier "BasileGT1050_NvidiaCard" Driver "nouveau" ## the BusID should be in decimal format ! Was 42 in hexa BusID "PCI:66:0:0" EndSection Section "Screen" Identifier "BasileBigScreen" Device "BasileAMD570Card" Monitor "BasileBigMonitor" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Section "Screen" Identifier "BasileSmallScreen" Device "BasileGT1050_NvidiaCard" Monitor "BasileSmallMonitor" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display"
Re: Xorg en "dual-head dual-graphics card AMD/ATI 570 + 6450"
On 7/18/19 2:18 AM, Basile Starynkevitch wrote: Bonsoir, (ce message est volontairement en HTML) Je suis sous Debian/Sid sur mon PC rimski, avec une carte mère haut de gamme et processeur AMD 2970WX, chipset X399 et 64Go de RAM et une capacité disque (aussi bien SSD que rotatifs) à faire des envieux -des téraoctets! Il a plusieurs PCs à la maison, mais ils sont tous sous Linux. Ma tendre épouse m'a offert récemment -pour mes 60 ans- un Samsung S34J550WQU <https://www.materiel.net/produit/201901110070.html> qui fonctionne isolément sans souci avec une Gigabyte Geforce GTX Nvidia 1050TI installé dans son PC à elle, sous Ubuntu 18.04, hermes (et à peu près aussi bien avec le pilote nouveau qu'avec le pilote propriétaire Nvidia; les différences étaient des problèmes de performance ou de lignes parasites à l'écran, sans importance ici). Ce Samsung S34J550WQU (très lourd à transporter!) a remplacé moralement mon précédent écran LG Flatron E2250V <https://www.lg.com/fr/moniteurs/lg-E2250V-PN-moniteur-lcd-led>. J'ai finalement échangé une des deux cartes graphiques de rimski avec celle dans le PC de mon épouse. J'ai donc maintenant les deux cartes graphiques suivantes % lspci|grep VGA 0b:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480] (rev ef) 42:00.0 VGA compatible controller: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] (rev a1) et ça fonctionne avec le xorg.conf ci-dessous. # fichier xorg.conf.rimski Section "ServerLayout" Identifier "X.org Multihead Basile patched" Screen 0 "BasileBigScreen" 0 0 Screen 1 "BasileSmallScreen" LeftOf "BasileBigScreen" InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" Option "Xinerama" 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" # Load "vnc" Load "radeon" 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 "BasileBigMonitor" VendorName "Samsung" ModelName "S34J550" EndSection Section "Monitor" Identifier "BasileSmallMonitor" VendorName "LG" ModelName "Flatron E2250V" EndSection Section "Device" Identifier "BasileAMD570Card" Driver "amdgpu" ## the BusID should be in decimal format ! Was 0b in hexa BusID "PCI:11:0:0" EndSection Section "Device" Identifier "BasileGT1050_NvidiaCard" Driver "nouveau" ## the BusID should be in decimal format ! Was 42 in hexa BusID "PCI:66:0:0" EndSection Section "Screen" Identifier "BasileBigScreen" Device "BasileAMD570Card" Monitor "BasileBigMonitor" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Section "Screen" Identifier "BasileSmallScreen" Device "BasileGT1050_NvidiaCard" Monitor "BasileSmallMonitor" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection J'ai mis plusieurs jours à comprendre que le BusID des cartes est *en décimal* dans ce fichier xorg.conf alors que lspci le donne en hexa. Librement -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France; (mobile phone: cf my web page / voir ma page web...)
Re: Xorg en "dual-head dual-graphics card AMD/ATI 570 + 6450"
Basile Starynkevitch, au 2019-07-18 : > et ce, malgré ce fichier xorg.conf ci - dessous... (obtenu par > Xorg -config, puis largement bidouillé). [...] > > Section "Device" > Identifier "BasileBigCard" [...] > Driver "amdgpu" > BusID "PCI:10:0:0" > EndSection > > > Section "Device" > Identifier "BasileSmallCard" [...] > Driver "amdgpu" > BusID "PCI:66:0:0" > EndSection [...] > Et mon noyau a > > rimski.x86_64 ~ 2:12 .0 % lsmod |grep amd [...] > drm_kms_helper200704 2 amdgpu,radeon Bonsoir Basile, J'ai l'impression que votre carte HD6450 est pilotée par le module "radeon" et non "amdgpu". Peut-être que vous devriez signaler à Xorg de travailler avec ces deux pilotes différents ; je ne sais pas à quel point c'est supporté cependant. Je ne crois pas que la HD6450 supporte "amdgpu" ; ma vieille HD4770, remplacée récement par une RX560, était trop ancienne pour "amdgpu" et ne fonctionnait qu'avec "radeon". À en juger par le chapitre suivant sur le Wiki d'Arch Linux, ce pourrait bien être aussi le cas de votre carte : https://wiki.archlinux.org/index.php/Xorg#AMD > Avez vous des idées pour m'aider? En espérant que ça aide effectivement, Amicalement, -- Étienne Mollier 5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D signature.asc Description: OpenPGP digital signature
Re: Xorg en "dual-head dual-graphics card AMD/ATI 570 + 6450"
On 7/18/19 7:35 AM, Basile Starynkevitch wrote: On 7/18/19 5:40 AM, Bernard Schoenacker wrote: je corrige le tir sur les modelines : # 3440x1440 @ 60.00 Hz (GTF) hsync: 89.40 kHz; pclk: 419.11 MHz Modeline "3440x1440_60.00" 419.11 3440 3688 4064 4688 1440 1441 1444 1490 -HSync +Vsync J'ai alors besoin d'une explication: Pourquoi les modelines sont nécessaires avec 2 cartes graphiques mais pas avec une seule? Au taf, j'ai eu il y quelque temps une config dual-head dual-graphics cards (en Nvidia) et je n'ai pas eu besoin de renseigner les modlines (mais j'y utilise du pilote Nvidia propriétaire, ce que ma conscience m'interdit de faire à la maison; je tiens à utiliser des pilotes libres chez moi, dans ma maison, car je suis un zélote du logiciel libre). Moi je pense que ça n'a rien à voir. Chacun des écrans marche sur chacune des deux cartes si la carte et l'écran étaient les seuls à être physiquement branchés (la carte graphique sur ma carte mère, et l'écran sur la carte graphique). Librement -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France; (mobile phone: cf my web page / voir ma page web...)
Re: Xorg en "dual-head dual-graphics card AMD/ATI 570 + 6450"
On 7/18/19 5:40 AM, Bernard Schoenacker wrote: je corrige le tir sur les modelines : # 3440x1440 @ 60.00 Hz (GTF) hsync: 89.40 kHz; pclk: 419.11 MHz Modeline "3440x1440_60.00" 419.11 3440 3688 4064 4688 1440 1441 1444 1490 -HSync +Vsync J'ai alors besoin d'une explication: Pourquoi les modelines sont nécessaires avec 2 cartes graphiques mais pas avec une seule? Moi je pense que ça n'a rien à voir. Chacun des écrans marche sur chacune des deux cartes si la carte et l'écran étaient les seuls à être physiquement branchés (la carte graphique sur ma carte mère, et l'écran sur la carte graphique). Librement -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France; (mobile phone: cf my web page / voir ma page web...)
Re: Xorg en "dual-head dual-graphics cards AMD/ATI 570 + 6450"
On 7/18/19 5:26 AM, Bernard Schoenacker wrote: bonjour, comme j'ai déjà cherché la solution pour configurer un écran en haute résolution : http://debian.2.n7.nabble.com/modelines-pour-un-moniteur-tft-27-quot-td4383483.html il faut s'occuper en premier de : Samsung S34J550WQU Non. Ca marche tout seul, sans aucun modline, quand on le branche tout seul. Le problème c'est bien /dual-head dual-graphics cards/ J'ai probablement mal posé mon problème./ / Quelle est la partie du long mél originel que vous n'avez pas comprise? J'y ai tenté de donné tous les détails pertinents. Librement -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France; (mobile phone: cf my web page / voir ma page web...)
Re: Xorg en "dual-head dual-graphics card AMD/ATI 570 + 6450"
- Mail original - > De: "Bernard Schoenacker" > À: "Basile Starynkevitch" > Cc: debian-user-french@lists.debian.org > Envoyé: Jeudi 18 Juillet 2019 05:26:12 > Objet: Re: Xorg en "dual-head dual-graphics card AMD/ATI 570 + 6450" > > bonjour, > > comme j'ai déjà cherché la solution pour configurer un écran > en haute résolution : > > http://debian.2.n7.nabble.com/modelines-pour-un-moniteur-tft-27-quot-td4383483.html > > il faut s'occuper en premier de : Samsung S34J550WQU > > donc par conséquent, je reprends le même chemin que j'avais indiqué : > > https://www.displayspecifications.com/en/model/d36914d7 > > ensuite, il faut chercher dans la base de données : > > https://www.mythtv.org/wiki/Modeline_Database#Samsung > > et pour la haute résolution : > https://arachnoid.com/modelines/ > > et le résultat donne : > > # 3440x1440 @ 75.00 Hz (GTF) hsync: 112.73 kHz; pclk: 533.87 MHz > Modeline "3440x1440_75.00" 533.87 3440 3712 4088 4736 1440 1441 1444 > 1503 -HSync +Vsync > > détail : > > 1: [H PIXELS RND] : 3440.00 > 2: [V LINES RND] : 1440.00 > 3: [V FIELD RATE RQD] :75.00 > 4: [TOP MARGIN (LINES)]: 0.00 > 5: [BOT MARGIN (LINES)]: 0.00 > 6: [INTERLACE] : 0.00 > 7: [H PERIOD EST] : 8.871154 > 8: [V SYNC+BP] :62.00 > 9: [V BACK PORCH] :59.00 > 10: [TOTAL V LINES] : 1503.00 > 11: [V FIELD RATE EST] :74.35 > 12: [H PERIOD] : 8.871147 > 13: [V FIELD RATE] :75.00 > > désolé, mais là je sèche vraiment car je ne peut pas vérifier si > c'est correct ... > en tout cas, j'ai déterré un très vieux pot pour faire une bonne > soupe. > > prière de recommencer la configuration pour la 2e sortie sur l'écran > annexe > > > merci pour votre aimable attention > > slt > bernard > bonjour, comme je n'ai pas tout dit, je continue à la suite : voici l'exemple que j'ai donné et qui est dans les archives de la liste : xrandr --newmode "1920x1080_60.00" 148.5 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync xrandr --addmode VGA-0 1920x1080_60.00 xrandr --output VGA-0 --mode 1920x1080_60.00 je corrige le tir sur les modelines : # 3440x1440 @ 60.00 Hz (GTF) hsync: 89.40 kHz; pclk: 419.11 MHz Modeline "3440x1440_60.00" 419.11 3440 3688 4064 4688 1440 1441 1444 1490 -HSync +Vsync il faut intégrer les paramètres dans un fichier .xinitrc : xrandr --newmode "3440x1440_60.00" 419.11 3440 3688 4064 4688 1440 1441 1444 1490 -HSync +Vsync # attention, il faut trouver "l'adresse" de la connexion si c'est une sortie VGA ou autre xrandr --addmode VGA-0 3440x1440_60.00 xrandr --output VGA-0 --mode 3440x1440_60.00 pour le 2e moniteur il faut faire de même en configurant les modelines et la sortie VGA-1 ou autre si c'est du hdmi merci slt bernard
Re: Xorg en "dual-head dual-graphics card AMD/ATI 570 + 6450"
bonjour, comme j'ai déjà cherché la solution pour configurer un écran en haute résolution : http://debian.2.n7.nabble.com/modelines-pour-un-moniteur-tft-27-quot-td4383483.html il faut s'occuper en premier de : Samsung S34J550WQU donc par conséquent, je reprends le même chemin que j'avais indiqué : https://www.displayspecifications.com/en/model/d36914d7 ensuite, il faut chercher dans la base de données : https://www.mythtv.org/wiki/Modeline_Database#Samsung et pour la haute résolution : https://arachnoid.com/modelines/ et le résultat donne : # 3440x1440 @ 75.00 Hz (GTF) hsync: 112.73 kHz; pclk: 533.87 MHz Modeline "3440x1440_75.00" 533.87 3440 3712 4088 4736 1440 1441 1444 1503 -HSync +Vsync détail : 1: [H PIXELS RND] : 3440.00 2: [V LINES RND] : 1440.00 3: [V FIELD RATE RQD] :75.00 4: [TOP MARGIN (LINES)]: 0.00 5: [BOT MARGIN (LINES)]: 0.00 6: [INTERLACE] : 0.00 7: [H PERIOD EST] : 8.871154 8: [V SYNC+BP] :62.00 9: [V BACK PORCH] :59.00 10: [TOTAL V LINES] : 1503.00 11: [V FIELD RATE EST] :74.35 12: [H PERIOD] : 8.871147 13: [V FIELD RATE] :75.00 désolé, mais là je sèche vraiment car je ne peut pas vérifier si c'est correct ... en tout cas, j'ai déterré un très vieux pot pour faire une bonne soupe. prière de recommencer la configuration pour la 2e sortie sur l'écran annexe merci pour votre aimable attention slt bernard
Xorg en "dual-head dual-graphics card AMD/ATI 570 + 6450"
Bonsoir, (ce message est volontairement en HTML) Je suis sous Debian/Sid sur mon PC rimski, avec une carte mère haut de gamme et processeur AMD 2970WX, chipset X399 et 64Go de RAM et une capacité disque (aussi bien SSD que rotatifs) à faire des envieux -des téraoctets! Il a plusieurs PCs à la maison, mais ils sont tous sous Linux. Ma tendre épouse m'a offert récemment -pour mes 60 ans- un Samsung S34J550WQU <https://www.materiel.net/produit/201901110070.html> qui fonctionne isolément sans souci avec une Gigabyte Geforce GTX Nvidia 1050TI installé dans son PC à elle, sous Ubuntu 18.04, hermes (et à peu près aussi bien avec le pilote nouveau qu'avec le pilote propriétaire Nvidia; les différences étaient des problèmes de performance ou de lignes parasites à l'écran, sans importance ici). Ce Samsung S34J550WQU (très lourd à transporter!) a remplacé moralement mon précédent écran LG Flatron E2250V <https://www.lg.com/fr/moniteurs/lg-E2250V-PN-moniteur-lcd-led>. La carte graphique AMD dans mon PC rimski est donc donnée par lspci -v comme: 42: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 145, NUMA node 2 Memory at 8000 (64-bit, prefetchable) [size=256M] Memory at 9000 (64-bit, prefetchable) [size=2M] I/O ports at 8000 [size=256] Memory at 9dc0 (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] 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 et commercialement cette carte graphique est une Asus EX RX570 O4G d'après sa facture donnée par materiel.net. Idéologiquement je déteste NVIDIA (le fameux "fuck you Nvidia" de Linus Torvards explique pourquoi) et à la maison mon ordinateur à moi préfère AMD à Nvidia. Et comme j'ai été opéré de la cataracte, j'y vois encore un peu mal (mais objectivement, la chirurgie de la cataracte a fait des miracles, et je suis ravi de mes nouveaux yeux 2.0). A 60 ans, j'aime me vautrer dans le luxe, et je souhaite même pouvoir, malgré la fabuleuse qualité de ce Samsung S34J550WQU <https://www.materiel.net/produit/201901110070.html> utiliser en plus mon ancien écran qui était un LG Flatron E2250V <https://www.lg.com/fr/moniteurs/lg-E2250V-PN-moniteur-lcd-led> (en effet je développe bismon <http://github.com/bstarynk/bismon/>, et j'ai besoin de plein d'écrans). J'ai essayé plein de choses pendant deux jours, mais en vain. J'avais lu quelque part que c'est galère de configurer Linux + Xorg + xrandr pour un écran logique de plus de 5000 pixels de large (et je crois que ça explique mes échecs, et je suis trop vieux pour investir une semaine de mon temps à débroussailler ce problème encore plus; même à la maison /time is money/ en ce qui concerne le temps consacré à l'administration système; je préfère m'éclater à développer du logiciel libre) Je viens d'acheter, pour brancher mon "ancien" écran LG Flatron E2250V, une carte graphique secondaire, Sapphire Radeon HD6450 2Gb <https://www.materiel.net/produit/201109010050.html> (ça coûte pas cher, et pour un écran secondaire, ça suffit amplement!). Elle est vue par lspci -v comme 0a:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited / Sapphire Technology Radeon HD 6450 1 GB DDR3 Flags: bus master, fast devsel, latency 0, IRQ 114, NUMA node 0 Memory at b000 (64-bit, prefetchable) [size=256M] Memory at c1f2 (64-bit, non-prefetchable) [size=128K] I/O ports at 3000 [size=256] Expansion ROM at c1f0 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Ex
Re : xorg lent à afficher le bureau
Le 19/02/2019 17:57:17, littlejoh...@laposte.net a écrit : > Pendant la durée interminable de l'écran noir, avez-vous essayé de > basculer dans une console en appuyant simultanément sur Ctrl+Alt+F2 ? À propos de Ctrl-Alt-Fx… chez moi, ça ne marche pas si j’ai une session ouverte (XFCE) mais ça marche si j’ai l’écran de bienvenue (WDM). Quelqu’un sait où ça se règle ? nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
RE: xorg lent à afficher le bureau
steve a écrit > Depuis que j'ai passé une machine sur le dernier noyau backport (le 4.19), > le bureau xfce prend une plombe à s'afficher. Pendant la durée interminable de l'écran noir, avez-vous essayé de basculer dans une console en appuyant simultanément sur Ctrl+Alt+F2 ? Est-ce que si, énervé d'attendre, vous déplacez la souris la situation s'améliore ? ( Si vous avez une souris sans fil pas la peine de faire cette manipulation car le démon bluetooth n'est pas démarré ). Je subodore un problème lié à un déficit d'entropie au moment du démarrage du système. Il se peut qu'avec le noyau 4.19 certains appels systèmes liés à l'entropie soient devenus bloquants. Vous pouvez installer le paquet haveged pour tenter de remplir plus rapidement le réservoir d'entropie du noyau. Cordialement, Regards, Mit freundlichen Grüßen, مع تحياتي الخالصة --- F. Petitjean Ingénieur civil du Génie Maritime. « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)
Re: xorg lent à afficher le bureau
Le 04/02/2019 à 16:04, steve a écrit : > Le 02-02-2019, à 17:38:45 +0100, Bruno Volpi a écrit : > >> peut-tu tester la commande : systemd-analyse blame > > J'avais fait[...] je n'ai jamais utilisé, mais d'après la description, systemd-bootchart est une version graphique et plus détaillée de systemd-analize Mes excuses à steve pour lui avoir répondu en privé, c'était involontaire et je ne m'en suis pas rendu compte tout de suite :-)
Re: xorg lent à afficher le bureau
Le 02-02-2019, à 17:38:45 +0100, Bruno Volpi a écrit : peut-tu tester la commande : systemd-analyse blame J'avais fait, et ce qui prenait le plus de temps était NetworkManager-wait-online.service (environ 5 s), et je l'ai donc désactivé mais ça n'a pas changé le comportement. tu vas voir ce qui prend du temps pour monter le system si le problème ne survient qu'au démarrage de startX vérifier les drivers de la carte graphiques ( Propriétaire ou générique) C'est le driver i915 (carte graphique intégrée). Pas trouvé de bug le concernant. Le mystère persiste… Merci pour la réponse. Steve
Re: xorg lent à afficher le bureau
Le 02/02/2019 à 17:38, Bruno Volpi a écrit : > peut-tu tester la commande : systemd-analyse blame Bonjour, Dans la langue des grands bretons, c'est systemd-analyze ^ -- -- Dominique Marin http://txodom.free.fr -- Comme ils disent à Varsovie : «Boire ou conduire ?... De toute façon, on n'a pas de voiture.» --Coluche -- pEpkey.asc Description: application/pgp-keys
Re: xorg lent à afficher le bureau
Le 02/02/2019 à 14:07, steve a écrit : Salut la liste, Je cherche, je cherche mais je n'ai plus d'idée, donc je poste ici. Depuis que j'ai passé une machine sur le dernier noyau backport (le 4.19), le bureau xfce prend une plombe à s'afficher. Le tout démarre super vite, puis écran noir et après environ 45 secondes, le bureau apparaît. Sur l'ancien noyau, un 4.9, tout se passait normalement. D'ailleurs si je redémarre sur le 4.9, tout est normal. Rien d'autre n'a été changé. Rien dans les logs (Xorg.0.log) et rien trouvé d'approchant sur le Net. N'ayant pas d'autre écran à disposition, je n'ai pas pu teste cette hypothèse. Toute idée serait la bienvenue. Merci. S Salut, peut-tu tester la commande : systemd-analyse blame tu vas voir ce qui prend du temps pour monter le system si le problème ne survient qu'au démarrage de startX vérifier les drivers de la carte graphiques ( Propriétaire ou générique) bruno
xorg lent à afficher le bureau
Salut la liste, Je cherche, je cherche mais je n'ai plus d'idée, donc je poste ici. Depuis que j'ai passé une machine sur le dernier noyau backport (le 4.19), le bureau xfce prend une plombe à s'afficher. Le tout démarre super vite, puis écran noir et après environ 45 secondes, le bureau apparaît. Sur l'ancien noyau, un 4.9, tout se passait normalement. D'ailleurs si je redémarre sur le 4.9, tout est normal. Rien d'autre n'a été changé. Rien dans les logs (Xorg.0.log) et rien trouvé d'approchant sur le Net. N'ayant pas d'autre écran à disposition, je n'ai pas pu teste cette hypothèse. Toute idée serait la bienvenue. Merci. S
Re: Question sur Xorg sous Debian Jessie
Le 09/03/2017 à 16:46, contact a écrit : pardon le mail est parti avant la fin ; un reconfiguration de XORg dpkg-reconfigure Xorg relance de X et pas de drivers chargé dans X le fichier Xorg.0.log reste sans trace de ce module nouveau *François-Marie BILLARD* Sculpteur - Céramiste Le 09/03/2017 à 16:42, contact a écrit : Du nouveau dans ce domaine : un désinstallation complète de nvidia de nouveau de bumblebee et compères. une installation de nvidia-installer-cleanup une suppression de ce même paquet installation de xserver-xorg-video-nouveau un modprobe nouveau et ce coup ci j'ai lspci -s 01:00.0 -vvv | grep -i driver Kernel driver in use: nouveau par contre l'ajout de bumblebee entraîne un blocage complet du PC au moment du modeprobe. un echo nouveau > /etc/modules *François-Marie BILLARD* Sculpteur - Céramiste Le 09/03/2017 à 14:11, didier gaumet a écrit : Le 09/03/2017 à 12:56, contact a écrit : Bon opération faites, le modprobe nouveau fige totalement mon pc. Un reboot Hard sur le bouton marche/arrêt remet la configuration en place. à mon avis le driver proprio nvidia n'a pas été désinstallé correctement et il pollue l'utilisation de nouveau. il faudrait rechercher tous les paquets nvidia installés (i) ou à-demi configurés (c) et les purger. réinstaller les paquets nvidia-installer-cleaner, xorg et nouveau serait une bonne chose supprimer le blacklist nouveau. vérifier que l'installateur nvidia proprio n'ait pas généré un xorg.conf quelque part. voir si il reste des mudules nvidia (je ne connais pas leur nom) qui devraient se trouver dans /lib/modules/*/kernel/drivers/gpu/drm voir aussi l'utilisation de bumblebee:https://wiki.debian.org/fr/Bumblebee sans avoir de carte nvidia ni de double config intel/nvidia je doute de pouvoir t'en dire beaucoup plus... Bonjour, Le driver "nouveau" n'a jamais fonctionné chez moi avec ces "anciens" chipset (style un pc Acer "full nvidia" sous Primtux ou un portable dont je ne me souviens plus la config) ; du moins cela se traduit par le même symptôme que vous rencontrez, c'est à dire sur un freeze total... En dépit du bon sens, seule l'installation du pilote propriétaire a résolu le problème sur ces pc. Votre carte graphique est pourtant dans cette liste : http://us.download.nvidia.com/XFree86/Linux-x86/304.125/README/supportedchips.html La procédure du wiki fonctionne (prendre le temps de lire ;-) https://wiki.debian.org/fr/NvidiaGraphicsDrivers#Version_304.131_.28processeurs_anciens.29 Sinon, je lisais ce post car je suis confronté au même problème que vous en ce moment (attention, je n'ai pas essayé sa solution, c'est pour demain) : http://www.allaboutlinux.eu/remove-nouveau-and-install-nvidia-driver-in-debian-8/ Bonne soirée, Christophe
Re: Question sur Xorg sous Debian Jessie
quelques pistes: - la désinstallation et la purge d'un paquet sont différentes: dans le second cas, les fichiers de configuration sont supprimés, pas dans le premier cas. pour repartir d'une conf propre après des problèmes il vaut mieux purger. je dis ça car tu as parlé de désinstallation... - fais un sudo find -name xorg.conf et si ça retourne quelque chose, regarde le(s) contenu(s) de ce(s) fichier(s): toute reférence au driver nvidia proprio est un problème - examine le log de xorg pour voir ce qui se passe quand il détecte la carte nvidia (tu peux d'abord chercher les codes EE pour erreur et affiner avec les codes WW pour warning), voir si ça cherche à appeler le driver proprio ou libre et bumblebee ou pas, etc... - c'est bien bumblebee et pas bumblebee-nvidia que tu as installé (en plus d'optimus)? as-tu rajouté ton nom d'utilisateur au group bumblebee? - normalement pas besoin d'ajouter nouveau à /etc/modules, il devrait être chargé automatiquement je ne pense pas pouvoir t'en dire beaucoup plus...
Re: Question sur Xorg sous Debian Jessie
pardon le mail est parti avant la fin ; un reconfiguration de XORg dpkg-reconfigure Xorg relance de X et pas de drivers chargé dans X le fichier Xorg.0.log reste sans trace de ce module nouveau *François-Marie BILLARD* Sculpteur - Céramiste Le 09/03/2017 à 16:42, contact a écrit : Du nouveau dans ce domaine : un désinstallation complète de nvidia de nouveau de bumblebee et compères. une installation de nvidia-installer-cleanup une suppression de ce même paquet installation de xserver-xorg-video-nouveau un modprobe nouveau et ce coup ci j'ai lspci -s 01:00.0 -vvv | grep -i driver Kernel driver in use: nouveau par contre l'ajout de bumblebee entraîne un blocage complet du PC au moment du modeprobe. un echo nouveau > /etc/modules *François-Marie BILLARD* Sculpteur - Céramiste Le 09/03/2017 à 14:11, didier gaumet a écrit : Le 09/03/2017 à 12:56, contact a écrit : Bon opération faites, le modprobe nouveau fige totalement mon pc. Un reboot Hard sur le bouton marche/arrêt remet la configuration en place. à mon avis le driver proprio nvidia n'a pas été désinstallé correctement et il pollue l'utilisation de nouveau. il faudrait rechercher tous les paquets nvidia installés (i) ou à-demi configurés (c) et les purger. réinstaller les paquets nvidia-installer-cleaner, xorg et nouveau serait une bonne chose supprimer le blacklist nouveau. vérifier que l'installateur nvidia proprio n'ait pas généré un xorg.conf quelque part. voir si il reste des mudules nvidia (je ne connais pas leur nom) qui devraient se trouver dans /lib/modules/*/kernel/drivers/gpu/drm voir aussi l'utilisation de bumblebee:https://wiki.debian.org/fr/Bumblebee sans avoir de carte nvidia ni de double config intel/nvidia je doute de pouvoir t'en dire beaucoup plus...
Re: Question sur Xorg sous Debian Jessie
Ok merci beaucoup pour cette aide, je vais essayer de nouveau avec ces informations. Cordialement *François-Marie BILLARD* Sculpteur - Céramiste Le 09/03/2017 à 14:11, didier gaumet a écrit : Le 09/03/2017 à 12:56, contact a écrit : Bon opération faites, le modprobe nouveau fige totalement mon pc. Un reboot Hard sur le bouton marche/arrêt remet la configuration en place. à mon avis le driver proprio nvidia n'a pas été désinstallé correctement et il pollue l'utilisation de nouveau. il faudrait rechercher tous les paquets nvidia installés (i) ou à-demi configurés (c) et les purger. réinstaller les paquets nvidia-installer-cleaner, xorg et nouveau serait une bonne chose supprimer le blacklist nouveau. vérifier que l'installateur nvidia proprio n'ait pas généré un xorg.conf quelque part. voir si il reste des mudules nvidia (je ne connais pas leur nom) qui devraient se trouver dans /lib/modules/*/kernel/drivers/gpu/drm voir aussi l'utilisation de bumblebee: https://wiki.debian.org/fr/Bumblebee sans avoir de carte nvidia ni de double config intel/nvidia je doute de pouvoir t'en dire beaucoup plus...
Re: Question sur Xorg sous Debian Jessie
Le 09/03/2017 à 12:56, contact a écrit : > Bon opération faites, le modprobe nouveau fige totalement mon pc. > > Un reboot Hard sur le bouton marche/arrêt remet la configuration en place. à mon avis le driver proprio nvidia n'a pas été désinstallé correctement et il pollue l'utilisation de nouveau. il faudrait rechercher tous les paquets nvidia installés (i) ou à-demi configurés (c) et les purger. réinstaller les paquets nvidia-installer-cleaner, xorg et nouveau serait une bonne chose supprimer le blacklist nouveau. vérifier que l'installateur nvidia proprio n'ait pas généré un xorg.conf quelque part. voir si il reste des mudules nvidia (je ne connais pas leur nom) qui devraient se trouver dans /lib/modules/*/kernel/drivers/gpu/drm voir aussi l'utilisation de bumblebee: https://wiki.debian.org/fr/Bumblebee sans avoir de carte nvidia ni de double config intel/nvidia je doute de pouvoir t'en dire beaucoup plus...
Re: Question sur Xorg sous Debian Jessie
Bon opération faites, le modprobe nouveau fige totalement mon pc. Un reboot Hard sur le bouton marche/arrêt remet la configuration en place. *François-Marie BILLARD* Sculpteur - Céramiste Le 09/03/2017 à 12:44, didier gaumet a écrit : Le 09/03/2017 à 12:18, contact a écrit : lspci -s ne renvoie rien ls /etc/modprobe.d amd64-microcode-blacklist.conf bumblebee.conf dkms.conf fbdev-blacklist.conf hostap-utils intel-microcode-blacklist.conf modesetting.conf nouveau-blacklist.conf les deux commandes semblent confirmer: - pour la première que le noyau ne charge pas de module (driver) pour ta carte graphique nvidia - pour la seconde que le module nouveau est interdit: fais une éventuelle copie de sauvegarde de /etc/modprobe.d/nouveau-blacklist.conf dans ton répertoire personnel (si tu souhaites pouvoir le réutiliser tel quel plus tard pour interdire le chargement du module nouveau, il te suffira de le replacer dans /etc/modprobe.d) et détruis-le. Le plus simple est ensuite de redémarre ta machine mais tu peux aussi faire un modprobe nouveau et un systemctl restart ton_display_manager, ton_display_manager étant par exemple lightdm si c'est celui que tu utilises.
Re: Question sur Xorg sous Debian Jessie
Le 09/03/2017 à 12:18, contact a écrit : > lspci -s ne renvoie rien > > ls /etc/modprobe.d > >> amd64-microcode-blacklist.conf bumblebee.conf dkms.conf >> fbdev-blacklist.conf hostap-utils intel-microcode-blacklist.conf >> modesetting.conf nouveau-blacklist.conf les deux commandes semblent confirmer: - pour la première que le noyau ne charge pas de module (driver) pour ta carte graphique nvidia - pour la seconde que le module nouveau est interdit: fais une éventuelle copie de sauvegarde de /etc/modprobe.d/nouveau-blacklist.conf dans ton répertoire personnel (si tu souhaites pouvoir le réutiliser tel quel plus tard pour interdire le chargement du module nouveau, il te suffira de le replacer dans /etc/modprobe.d) et détruis-le. Le plus simple est ensuite de redémarre ta machine mais tu peux aussi faire un modprobe nouveau et un systemctl restart ton_display_manager, ton_display_manager étant par exemple lightdm si c'est celui que tu utilises.
Re: Question sur Xorg sous Debian Jessie
lspci -s ne renvoie rien ls /etc/modprobe.d amd64-microcode-blacklist.conf bumblebee.conf dkms.conf fbdev-blacklist.conf hostap-utils intel-microcode-blacklist.conf modesetting.conf nouveau-blacklist.conf *François-Marie BILLARD* Sculpteur - Céramiste Le 09/03/2017 à 11:56, didier gaumet a écrit : lspci -s 01:00.0 -vvv | grep -i driver
Re: Question sur Xorg sous Debian Jessie
essaie un: lspci -s 01:00.0 -vvv | grep -i driver pour voir quel module utilise ou tente d'utiliser le noyau linux pour ta carte Nvidia et ls /etc/modprobe.d pour voir si il ne traîne pas quelque chose qui empêcherait le module nouveau d'être chargé
Re: Question sur Xorg sous Debian Jessie
une install du paquet nvidia-installer-cleanup une reinstall du xserver-xorg-video-nouveau les firmwares ii amd64-microcode 2.20160316.1~deb8u1 amd64 Processor microcode firmware for AMD CPUs ii firmware-atheros 0.43 all Binary firmware for Atheros wireless cards ii firmware-iwlwifi 0.43 all Binary firmware for Intel Wireless cards ii firmware-linux 0.43 all Binary firmware for various drivers in the Linux kernel (meta-package) ii firmware-linux-free 3.3 all Binary firmware for various drivers in the Linux kernel ii firmware-linux-nonfree 0.43 all Binary firmware for various drivers in the Linux kernel ii heimdall-flash 1.4.0-2 amd64 tool for flashing firmware on Samsung Galaxy S devices ii heimdall-flash-frontend 1.4.0-2 amd64tool for flashing firmware on Samsung Galaxy S devices - Qt GUI ii intel-microcode 3.20161104.1~deb8u1 amd64 Processor microcode firmware for Intel CPUs et rien de mieux, pas de chargement de ce drivers Nouveau. *François-Marie BILLARD* Sculpteur - Céramiste Le 09/03/2017 à 11:13, contact a écrit : Bonjour merci en fait j'ai une NVIDIA Quadro 1000M lspci : 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 01:00.0 VGA compatible controller: NVIDIA Corporation GF108GLM [Quadro 1000M] (rev ff) *François-Marie BILLARD* Sculpteur - Céramiste Le 09/03/2017 à 11:11, didier gaumet a écrit : en fouillant un peu, j'ai trouvé: - que tu dois avoir une Nvidia Quadro fx 2000 qui est déjà assez ancienne donc supportée depuis un certain temps par le driver libre nouveau, donc je pense que tu peux rester en Jessie sans problème - que tu as semble-t-il utilisé le driver nvidia propriétaire par le passé, donc peut-être reste-il des cories qui empêchent le fonctionnement de nouveau (si il est installé). Une solution semble d'installer le paquet nvidia-installer-cleaner qui remet la configuration d'équerre après la désinstallation du driver proprio nvidia
