Matériel: APU2D0 Version de YunoHost: 4.0.8 J’ai accès à mon serveur : En SSH | Par la webadmin | Via port série Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non, mis à part que mon serveur est sur une partition chiffrée avec LUKS
Description du problème
Bonjour,
Depuis la mise à jour vers Buster, je ne peux pas utiliser les nouveaux noyaux disponibles. Dès que je charge sur les nouvelles versions (la dernière version testée étant la 4.19.0-11, mais c’était pareil avec celle d’avant), un processus nommé kworker consomme quasiment toutes les ressources de mon CPU, et mon serveur devient inutilisable au bout de quelques minutes. À noter que sur la capture d’écran, c’est le processus kworker/1:2H+kblockd qui est le plus consommateur mais cela change parfois au profit de kworker/2:1H+kblockd ou kworker/3:1H+kblockd.
J’ai bien essayé de le laisser tourner une nuit entière pour voir si cela se résout au bout d’un moment mais mon serveur devient injoignable, que ce soit par ssh ou par la webadmin.
Par ailleurs, il semble impossible de tuer le processus via une commande kill.
J’utilise donc pour l’instant l’ancien noyau que j’avais sous Stretch, c’est à dire la version 4.9.0-11. Je n’ai aucun souci avec celui-ci, mais j’ai peur qu’il soit un peu vieux et que ça ne soit pas terrible niveau sécurité.
Je ne sais pas du tout à quoi cela peut être dû. Par où pourrais-je commencer pour en savoir plus sur la nature de ce processus afin qu’il ne consomme plus toutes les ressources du CPU ?
Comme toutes les valeurs sont à 0, je n’ai pas été plus loin car si je comprends bien je dois chercher une valeur élevée.
Par rapport à l’autre topic, je n’ai pas de fichier /etc/udev/rules.d/70-persistent.net.rules. Par ailleurs mon interface réseau n’a pas changé de nom entre les deux versions (était et est toujours enp1s0).
J’ai aussi essayé de stopper le service nfs (que je n’utilise pas, mais on ne sait jamais) comme c’était mentionné dans une des réponse, mais ça ne change rien non plus.
Une autre possibilité est d’essayer un autre kernel que celui que tu utilises actuellement, idéalement un kernel plus récent (par exemple via buster-backports) ou (moins bien mais marche parfois) un kernel plus ancien.
Autre piste : vu que c’est du matériel un peu “exotique” contacter https://www.pcengines.ch/apu2d0.htm pour leur demander si ils ont une idée. Je pense qu’ils sont sensibles au support kernel sous debian…
En allant sur le site de PCEngines, j’ai vu qu’on pouvait également faire la mise à jour du BIOS. J’ai essayé pour voir si ça changeait quelque chose, mais malheureusement c’est sans effet.
La dernière version du kernel (4.19.0-12) n’a pas mieux marché, mais j’essaierai de voir avec les versions disponibles dans les backports quand j’aurai un peu de temps. Sinon effectivement contacter PCEngines peut être intéressant.
Je ferai un retour si jamais je trouve la solution.
J’ai trouvé une solution !
Comme j’ai cru comprendre que ça venait d’un problème lié au matériel, j’ai désactivé une à une les différentes options du BIOS pour voir si le problème se résolvait. En désactivant le mode SD 3.0, cela a résolu le problème et kworker ne pose plus aucun souci sur les derniers noyaux (testé avec le 4.19.0-12 et le 5.8.0 des dépôts backports).
Je ne sais pas trop si cette fonction était très utile, mais en tout cas tout semble fonctionner correctement.
