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/
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: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] 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
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 :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: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 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 :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...
