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 0000: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 0000:00:02.0: [drm] GPU HANG: ecode 11:1:86dffffd, 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 <etienne.mollier@mailoo.org> Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity.
Attachment:
signature.asc
Description: PGP signature