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'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 ?
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'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 ?
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'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 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.
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.
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.
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.
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.
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.
Je teste ça et je vous dis dans qq j si ça a réglé le pb.
Je teste ça et je vous dis dans qq j si ça a réglé le pb.
Je teste ça et je vous dis dans qq j si ça a réglé le pb.
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 0000:00:02.0: [drm] Resetting rcs0 for preemption time out
Jun 14 19:43:01 dell kernel: [22501.752684] i915 0000:00:02.0: [drm] Xorg[1988] context reset due to GPU hang
Jun 14 19:43:01 dell kernel: [22501.763575] i915 0000:00:02.0: [drm] GPU HANG: ecode 11:1:86dffffd, in Xorg [1988]
Jun 15 14:11:02 dell kernel: [19659.973156] i915 0000:00:02.0: [drm] Resetting rcs0 for preemption time out
Jun 15 14:11:02 dell kernel: [19659.973181] i915 0000:00:02.0: [drm] Xorg[2180] context reset due to GPU hang
Jun 15 14:11:02 dell kernel: [19659.980708] i915 0000:00:02.0: [drm] GPU HANG: ecode 11:1:86dffffd, in Xorg [2180]
/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)
Le 14/06/21 ̓ 13:25, Daniel Caillibaud <ml@lairdutemps.org> 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 0000:00:02.0: [drm] Resetting rcs0 for preemption time out
Jun 14 19:43:01 dell kernel: [22501.752684] i915 0000:00:02.0: [drm] Xorg[1988] context reset due to GPU hang
Jun 14 19:43:01 dell kernel: [22501.763575] i915 0000:00:02.0: [drm] GPU HANG: ecode 11:1:86dffffd, in Xorg [1988]
Jun 15 14:11:02 dell kernel: [19659.973156] i915 0000:00:02.0: [drm] Resetting rcs0 for preemption time out
Jun 15 14:11:02 dell kernel: [19659.973181] i915 0000:00:02.0: [drm] Xorg[2180] context reset due to GPU hang
Jun 15 14:11:02 dell kernel: [19659.980708] i915 0000:00:02.0: [drm] GPU HANG: ecode 11:1:86dffffd, in Xorg [2180]
/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)
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 0000:00:02.0: [drm] Resetting rcs0 for preemption time out
Jun 14 19:43:01 dell kernel: [22501.752684] i915 0000:00:02.0: [drm] Xorg[1988] context reset due to GPU hang
Jun 14 19:43:01 dell kernel: [22501.763575] i915 0000:00:02.0: [drm] GPU HANG: ecode 11:1:86dffffd, in Xorg [1988]
Jun 15 14:11:02 dell kernel: [19659.973156] i915 0000:00:02.0: [drm] Resetting rcs0 for preemption time out
Jun 15 14:11:02 dell kernel: [19659.973181] i915 0000:00:02.0: [drm] Xorg[2180] context reset due to GPU hang
Jun 15 14:11:02 dell kernel: [19659.980708] i915 0000:00:02.0: [drm] GPU HANG: ecode 11:1:86dffffd, in Xorg [2180]
/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)
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.)
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?pid03409#p1903409
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.)
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?pid03409#p1903409
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.)
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?pid03409#p1903409
J'ai commencé par mettre les options
intel_idle.max_cstate=1 i915.enable_dc=0
J'ai commencé par mettre les options
intel_idle.max_cstate=1 i915.enable_dc=0
J'ai commencé par mettre les options
intel_idle.max_cstate=1 i915.enable_dc=0
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)
Le 16/06/21 ̓ 13:13, Daniel Caillibaud <ml@lairdutemps.org> 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)
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.
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.
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.
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.
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.
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.
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
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
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