Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Plantages Xorg (i915, context reset due to GPU hang)
217 views
Skip to first unread message
Daniel Caillibaud
Jun 10, 2021, 12:00:03 PM6/10/21
to
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 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 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=10000
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
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 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=10000
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
Étienne Mollier
Jun 11, 2021, 5:40:03 PM6/11/21
to
Bonsoir Daniel,
Daniel Caillibaud, on 2021-06-10:
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...@mailoo.org>
Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
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
> 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]
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.
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 ?
- 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...@mailoo.org>
Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
Daniel Caillibaud
Jun 14, 2021, 7:30:03 AM6/14/21
to
Bonsoir,
Le 11/06/21 à 23:30, Étienne Mollier <etienne...@mailoo.org> a écrit :
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
Le 11/06/21 à 23:30, Étienne Mollier <etienne...@mailoo.org> 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.
> 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.
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.
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
Daniel Caillibaud
Jun 15, 2021, 8:40:02 AM6/15/21
to
Le 14/06/21 à 13:25, Daniel Caillibaud <m...@lairdutemps.org> a écrit :
ç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]
après un boot un `grep i915 /vl/kern.log` me donne ça
Jun 15 14:12:15 dell kernel: [ 1.325096] i915 0000:00:02.0: vgaarb: deactivate vga console
Jun 15 14:12:15 dell kernel: [ 1.357265] i915 0000: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 0000: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 0000: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 0000: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 0000: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 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
Jun 15 14:12:15 dell kernel: [ 12.669407] snd_hda_intel 0000:00:1f.3: bound 0000: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.
> 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]
après un boot un `grep i915 /vl/kern.log` me donne ça
Jun 15 14:12:15 dell kernel: [ 1.325096] i915 0000:00:02.0: vgaarb: deactivate vga console
Jun 15 14:12:15 dell kernel: [ 1.357265] i915 0000: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 0000: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 0000: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 0000: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 0000: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 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
Jun 15 14:12:15 dell kernel: [ 12.669407] snd_hda_intel 0000:00:1f.3: bound 0000: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.
Étienne Mollier
Jun 15, 2021, 2:10:03 PM6/15/21
to
Bonjour Daniel,
Daniel Caillibaud, on 2021-06-15:
[…]
> /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 <emol...@emlwks999.eu>
Daniel Caillibaud, on 2021-06-15:
> Le 14/06/21 à 13:25, Daniel Caillibaud <m...@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]
Argh, dommage, bon au moins, ça valait le coup d'essayer…
> > 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
Ç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)
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 <emol...@emlwks999.eu>
Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Sent from /dev/tty1, please excuse my verbosity.
Daniel Caillibaud
Jun 16, 2021, 7:20:03 AM6/16/21
to
Le 15/06/21 à 19:40, Étienne Mollier <emol...@emlwks999.eu> a écrit :
> […]
> > /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
> 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.)
[ 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
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
Daniel Caillibaud
Jul 1, 2021, 5:10:05 AM7/1/21
to
Le 16/06/21 à 13:13, Daniel Caillibaud <m...@lairdutemps.org> a écrit :
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
> J'ai commencé par mettre les options
> intel_idle.max_cstate=1 i915.enable_dc=0
Ça n'a rien changé.
> intel_idle.max_cstate=1 i915.enable_dc=0
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
Étienne Mollier
Jul 1, 2021, 2:40:03 PM7/1/21
to
Bonjour Daniel,
Daniel Caillibaud, on 2021-07-01:
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,
Pour référence :
[1] : https://downloads.slack-edge.com/linux_releases/slack-desktop-4.17.0-amd64.deb
Daniel Caillibaud, on 2021-07-01:
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 <emol...@emlwks999.eu>
Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Sent from /dev/pts/0, please excuse my verbosity.
Étienne Mollier <emol...@emlwks999.eu>
Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Pour référence :
[1] : https://downloads.slack-edge.com/linux_releases/slack-desktop-4.17.0-amd64.deb
Daniel Caillibaud
Jul 2, 2021, 3:50:03 AM7/2/21
to
Le 01/07/21 à 20:30, Étienne Mollier <emol...@emlwks999.eu> a écrit :
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/…)
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
> 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
> 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 ?
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/…)
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.
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
Daniel Caillibaud
Jul 2, 2021, 4:00:03 AM7/2/21
to
Le 01/07/21 à 21:03, BERTRAND Joël <joel.b...@systella.fr> 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.
> 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.
Daniel Caillibaud
Jul 2, 2021, 12:10:03 PM7/2/21
to
Le 02/07/21 à 10:18, BERTRAND Joël <joel.b...@systella.fr> 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
> 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
0 new messages