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