Sur une SBC Raxa Rock5b, (Rockchip rk3588) j'ai le serveur Xorg qui plante, que ce soit avec le kernel vendeur Rockchip en 6.1.x ou avec un plus récent en 6.12.y.
Cela se produit essentiellement en navigant sur le web avec FF
Dans /var/log/kern.log je vois:
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/user@1000.service/session.slice/gvfs-daemon.service,task=gvfsd-http,pid=5575,uid=1000
2025-09-19T17:22:31.776205+02:00 rock-5b kernel: [42310.637880] Out of memory: Killed process 5575 (gvfsd-http)
je ne vois pas vraiment le rapport entre le gnome virtual file system et mon pb.
J'essaye de surveiller la charge mémoire: FF dépasse rarement les 30% d'usage. Par contre je note parfois un fort ralentissement de l'interface graphique.
Plus d'infos:
Armbian 25.8.1 (base Bookworm)
Noyau 6.12.44-current-rockchip64
X11 + lightdm + Cinnamon
Graphics:
Device-1: display-subsystem driver: rockchip_drm v: N/A bus-ID: N/A
chip-ID: rockchip:display-subsystem class-ID: display-subsystem
Device-2: rk3588-mali driver: panthor v: kernel bus-ID: N/A
chip-ID: rockchip:fb000000 class-ID: gpu
Device-3: rk3588-dw-hdmi-qp driver: dwhdmiqp_rockchip v: N/A bus-ID: N/A
chip-ID: rockchip:fde80000 class-ID: hdmi
Display: x11 server: X.Org v: 1.21.1.7 driver: X: loaded: modesetting
unloaded: fbdev dri: rockchip
gpu: cdn-dp,dw-mipi-dsi-rockchip,dwhdmi-rockchip,dwhdmiqp-rockchip,innohdmi-rockchip,rockchip-dp,rockchip-drm,rockchip-lvds,rockchip-rk3066-hdmi,rockchip-vop,rockchip-vop2
display-ID: :0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
s-diag: 582mm (22.93")
Monitor-1: HDMI-A-1 mapped: HDMI-1 model: Philips 221V
res: 1920x1080 hz: 60 dpi: 102 size: 477x268mm (18.78x10.55")
diag: 547mm (21.5") modes: max: 1920x1080 min: 720x400
API: OpenGL v: 3.1 Mesa 25.0.7-2~bpo12+1 renderer: Mali-G610 (Panfrost)
direct-render: Yes
et j'ai dans dmesg les infos suivantes:
[42310.619796] Out of memory: Killed process 1601 (dbus-daemon) total-vm:9036kB, anon-rss:640kB, file-rss:960kB, shmem-rss:0kB, UID:1000 pgtables:56kB oom_score_adj:200
[42310.637303] systemd-journal invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=-250
[42310.637316] CPU: 6 UID: 0 PID: 536 Comm: systemd-journal Tainted: G C 6.12.44-current-rockchip64 #1
[42310.637320] Tainted: [C]=CRAP
[42310.637321] Hardware name: Radxa ROCK 5B (DT)
[42310.637322] Call trace:
[42310.637323] dump_backtrace+0x94/0x114
[42310.637329] show_stack+0x18/0x24
[42310.637331] dump_stack_lvl+0x74/0x8c
[42310.637335] dump_stack+0x18/0x24
[42310.637337] dump_header+0x3c/0x1a4
[42310.637343] oom_kill_process+0x130/0x34c
[42310.637345] out_of_memory+0xe4/0x568
(...)
Vous auriez une idée de ce qui peut bien se passer ?
# C'est un problème de mémoire (OOM)
Posté par cg . Évalué à 2 (+0/-0).
OOM = Out of memory.
Il y a combien de RAM sur la carte que tu as ? Les specs disent de 4GB à 32GB.
[^] # Re: C'est un problème de mémoire (OOM)
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
4Go maintenant, NOW.
mais je possede une autre Rock5B qui a 8Go de RAM -et le meme OS-). Je rencontre exactement les memes soucis ! Donc, je ne suis pas sur que ce soit lié à la quantité de RAM.
Cette réponse est envoyée sous LXQT sans les Gnome bells and whistles
(car, selon mes souvenirs récents. ca peut planter aussi sous LXQT)
Je ne suis pas sur que mon pb soit explicitement lié a
gvfsd-httpmais il est plus probable que ce soit une mauvaise gestion de la RAM par lOS et que un processus quelconque mette le oai partout (*) ans crier gare… je dois avouer que je ne connais pas granchose sur ce sujetCULTURELLEMENT NOTRE ARME C'EST LA MUSIQUE
PAS DE BLABLABLA J'AI DIT0 PAS DE RHETORIQUE
LES MOTS JUSTEMENT PLACE SUR LA RYTHMIQUE
EN PATOIS , EN FRANÇAIS , CA FRAPPE LA DIALECTIQUE
(…)
ON MET LO OAI PARTOUT(x4)
"Si tous les cons volaient, il ferait nuit" F. Dard
# charge mémoire
Posté par gaaaaaAab . Évalué à 3 (+1/-0).
et celle de gvfsd-http ?
De ce que je comprends, quand le système manque de mémoire, oom_killer flingue un processus gourmand en mémoire. S'il choisit gvfsd-http, ça doit être parce qu'il consomme beaucoup à ce moment là.
pour la conso de FF, si tu utilises beaucoup d'onglets, ça vaut p-e le coup d'activer l'option browser.tabs.unloadOnLowMemory
[^] # Re: charge mémoire
Posté par Luc-Skywalker . Évalué à 2 (+0/-0).
Sous LxQt, le service gvfsd-http ne tourne pas (il y en a d'autres en gvfsf-*** mais ils n'ateignent pas 1% de mémoire chacun) et si j'ai eu un crash de FF ce matin, je n'ai pas eu de plantage de X11.
C'est aussi mon interprétation, mais ce qui m'étone c'est que
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: charge mémoire
Posté par Luc-Skywalker . Évalué à 2 (+0/-0).
Je suis retourné sous Cinnamon et pas de plantage malgré une session FF bien chargée depuis une heure.
Comme gvfsd-http ne tourne pas en arrière plan actuellement, c'est peut être bien lui le coupable.
Je ne sais même pas pourquoi j'ai eu besoin de ce service qui sert à monter dans le système de fichier des ressources distantes via http.
"Si tous les cons volaient, il ferait nuit" F. Dard
# gkrellm
Posté par BAud (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 21 septembre 2025 à 12:45.
tu peux avoir un
gkrellmd'activé pour surveiller l'historique de ce qui se passe lors de tes soucis .tu le mets sur la droite au premier plan et sur tous les bureaux — comme ça toujours visible — et tu le redimensionne à 200 pour avoir un bon graphe d'historique.
Comme ça tu pourras voir la conso CPU, les I/O, la mémoire (RAM et swap) utilisée, tu peux afficher les 3 processus les plus consommateurs.
Sur Mageia l'OOM n'est pas activé par défaut, sur Debian j'ai toujours l'impression de laisser l'ordi jouer à
psdoomo_Oavec 4 Go de RAM, tu as sans doute des onglets qui se rafraîchissent dans Firefox — ce qui est plutôt mal géré en terme de conso RAM (plutôt que fire & forget, ça s'accumule comme si tu allais consulter l'historique o_O) — ça a tendance à démultiplier les processus (et les réveiller régulièrement), outre une conso RAM absurde, même avec 10 onglets. Autant je peux avoir 20 onglets de LinuxFr.org ouverts, autant 4-5 onglets avec lemonde.fr ou tv-programme.com et c'est la débauche de conso I/O et RAM et des latences…
et là tu as l'OOM qui se déclenche et tire à vue /o\
Bon, après ton GPU mali a un pilote un peu expérimental de mémoire, ça vaudrait le coup de regarder les logs de Xorg pour voir s'il remonte des infos.
[^] # Re: gkrellm
Posté par Luc-Skywalker . Évalué à 2 (+0/-0).
gvfsd-http est innocent. C'était même une victime !
oui, je viens d'en faire l'expérience. Etaient ouverts FreeCad et QGis, chacun avec des gros fichiers et pas mal d'onglets dans FF (dont des gros pdf).
Effectivement fermer quelques onglets de FF libère plusieurs centaines de Mo de RAM.
Mais bon, badaboum.
Ensuite je vois dans les logs que plein de processus ont été tués (genre pulseaudio qui n'y est pour rien)
C'est pas que je sois choqué (je suis un adepte du Ctrl Alt Backspace ou de xkill), mais juste un peu étonné que là, toute la session s’effondre.
Après, Armbian adopte par défaut une utilisation de la mémoire un peu spéciale (bien adptée aux SBC qui tournent sur carte SD selon moi):
le répertoire log et la swap sont chacun dans un Ramdisk. Celui de la swap alloue 1.8 Go et est parfois plein.
=> Je me demande si passer la swap sur le disque dur NVMe et libérer de la RAM pourrait arranger les choses.
PS: merci pour gkrellm, c'est pratique pour le coup. Par contre je n'arrive pas à avoir
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: gkrellm
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 21 septembre 2025 à 20:13.
il faut installer le greffon gkrelltop et l'activer
ah et j'ai oublié : passer le nombre de mesures à 1 par seconde, ça suffit bien ; c'est absurde d'en avoir toutes les 100 ms ça bouffe de la CPU pour rien
utilise evince pour lire des PDF, Firefox est sous-optimal (et consommateur en RAM pour cela)
ah, bah en réalité tu n'as donc que 2 Go de RAM utilisables : là oui, à cause du fonctionnement de Firefox cela devient insuffisant :/
tu peux fournir un
top | head -5pris dans les conditions de tes soucis ? l'OOM est assez tatillon sur la RAM libre (non affectée), il a tendance à se déclencher quand ça passe en dessous de 50 Mo :/[^] # Re: gkrellm
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Alors ça, mettre le swap dans la RAM, c'est un peu le chien qui court après sa queue.
Le swap, ça sert à décharger la RAM quand elle devient trop pleine, mais si on la remplit avec des données dont on a provisoirement pas besoin en RAM, ça ne risque pas de tuer des petits chatons mignons ?
[^] # Re: gkrellm
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
J'ai oublié de préciser que c'est de la zram.
Mais oui, je suis d'accord:
Çà se comprend sur les petites SBC sans disque dur, ou l'on veut éviter d’écrire effacer la carte SD. Mais là, dans mon cas, il me semble que c'est pas très judicieux.
En plus je suppose que comprimer et décomprimer à la volée, cela doit augmenter la charge sur le CPU.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: gkrellm
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Pour continuer à tester, peut-être mettre temporairement le swap sur une clef USB ?
[^] # Re: gkrellm
Posté par Luc-Skywalker . Évalué à 2 (+0/-0).
J'ai de la place sur le DD :)
Mais je verrai ça plus tard.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: gkrellm
Posté par Computer (site web personnel) . Évalué à 3 (+2/-0).
Tu as peut-être une fuite mémoire sur un logiciel que tu utilise. Le oom est très mauvais pour trouver le véritable coupable. Faut surveiller du côté de top&co.
Et surveiller aussi tout ce qui est en ramdisk surtout si tu laisses ton ordi allumé longtemps. Effectivement les logs peuvent être un soucis, /tmp l'est aussi parfois.
# Accélération matérielle
Posté par Tarnyko (site web personnel) . Évalué à 3 (+1/-0).
Xorg n'est pas censé crasher comme ça, juste parce qu'un processus random est abattu par l'OOM.
Par contre, j'ai déjà vu des interactions pourries d'applications accélérées par GPU (Chrome, Firefox) avec le pilote graphique, qui est du coup le soutien de Xorg.
Qu'est-ce que ça donne en désactivant l'Accelération matérielle dans les params FF (quitte à ce que ça soit + lent, mais pour tester) ?
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.