Mise à jour – Deux personnes ont désormais signalé exactement le même problème sur le forum de support de Proxmox.
Je serais curieux de savoir si quelqu’un d’autre a observé un comportement étrange avec le noyau 6.14.11-1-pve.
Immédiatement après la mise à jour vers le noyau 6.14.11-1-pve, l’un des serveurs Proxmox de mon labo maison a présenté des erreurs du noyau, une charge moyenne élevée et une extrême lenteur.
Après un redémarrage avec le noyau 6.8.12-13-pve, tout fonctionnait correctement.
Cela semble être un cas particulier, car mes autres nœuds semblent fonctionner correctement avec le dernier noyau.
Spécifications de la machine : Dell XPS 8960
Processeur Intel(R) Core(TM) i7-14700 avec 28 cœurs
64 Go de RAM
Disque dur de 1 To – Système d’exploitation
NVME de 4 To – volumes Ceph
Réseau principal – Contrôleur Realtek Semiconductor Co., Ltd. Killer E3000 2.5GbE
Réseau DMZ – Intel Corporation 82575EB Gigabit Network Connection
Réseau de pulsation Ceph – Intel Corporation 82575EB Gigabit Network Connection
Je viens d’avoir une réponse de quelqu’un sur le forum de support de Proxmox qui rencontre exactement le même problème :
Kernel panic avec 6.14.11-1-pve
Tout fonctionne correctement avec 6.8.12-14-pve
De plus en plus étrange
Je ne pense pas que vous puissiez affirmer « Il y a définitivement un problème avec la série du noyau 6.14 » quand seulement un de vos nœuds en est affecté (et très probablement, vu le nombre de publications sur Reddit, que vous soyez le seul à rencontrer ce problème).
La seule chose que vous puissiez faire est de comparer les nœuds fonctionnels avec les nœuds défaillants pour isoler la cause. Mon intuition penche pour des problèmes liés aux pilotes.
Naturellement, je n’exclus rien pour l’instant, mais j’évalue les probabilités. Est-il possible qu’un problème soit resté caché pendant 2 ans, ait soudainement refait surface au démarrage du noyau 6.14, puis ait disparu à nouveau après le retour au noyau 6.8 ? Bien sûr, mais c’est peu probable.
Bien que les nœuds soient tous des modèles différents, ils se ressemblent comme deux gouttes d’eau en termes de configuration.
Je suis assez vieux pour avoir connu des mises à jour du noyau qui causaient des problèmes, et qui ont été corrigées par la suite. Le verdict n’est pas encore tombé sur celui-ci. Pour l’instant, tout fonctionne parfaitement avec le noyau 6.8.
Je recueillerai plus d’informations sur le noyau bogué quand le temps me le permettra.
Je ne dis pas qu’il n’y a pas de bogue, mais j’ai vu des symptômes similaires (c’est-à-dire mise à niveau -> problème, rétrogradation -> pas de problème –> blâmer la mise à niveau) plusieurs fois.
Le plus fréquent est Python. J’ai des scripts qui ont arrêté de fonctionner (ou affichaient des avertissements) avec une version plus récente de Python mais pas avec les versions plus anciennes.
J’ai même eu une barrette de RAM défectueuse qui fonctionnait correctement sur Ubuntu 20.04 mais provoquait un panique du noyau sur Ubuntu 24.04. J’ai fait un test memtest et cela a confirmé la barrette de RAM défectueuse, mais je pouvais le faire sur 20.04 pendant des jours sans problème. Pourquoi ? Je n’en ai aucune idée. Le microcode ? Peut-être même que le noyau plus récent écrit trop souvent à une adresse spécifique qui a tendance à échouer.
Dans votre cas, vous pouvez choisir de rester sur un noyau moins récent (pas si différent de ma décision de rester sur une version plus ancienne de Python pour m’assurer que mes scripts fonctionnent) si cela signifie que votre problème ne se produit pas.
Je dis juste, étant donné que le problème ne se produit pas dans l’ensemble pour vous, je pointerai mon doigt vers une instabilité plus spécifique à ce serveur en particulier et non pas de manière générale vers le noyau.
Oui, vous avez raison sur ce point. On verra comment cela évolue.
Bonjour Apachez,
Tous les nœuds sont des modèles Dell différents, avec des processeurs légèrement différents.
Le problème ne s’est jamais produit pendant l’année de fonctionnement de la machine. Il est apparu pour la première fois après le démarrage avec le noyau 6.14 ce matin.
J’ai vérifié en démarrant avec différents noyaux, plusieurs fois chacun. Avec la série 6.8, tout va bien, et avec la série 6.14, la charge moyenne dépasse 20 en quelques minutes.
Toutes les mises à jour sont à jour.
But then you have something else thats malfunctioning.
Check with top/htop/btop or even ps to find out which processes that is that consume 20.0 in system load after a few minutes?
Unless you got like 20 VM’s all peaking at once that shouldnt happen.
There also seems to be some ongoing issue with intel drivers.
Verifiy with « lspci -vvv » which kernel modules are currently being used.
You can try the workaround for the intel nics as in disable all offloading features and then enable them one by one to find out which might be the issue (even if it doesnt sounds like this would be the case in your case).
Here is what I found in another post at reddit as workaround for the Intel NIC issue:
apt install -y ethtool
ethtool -K eth0 gso off gro off tso off tx off rx off rxvlan off txvlan off sg off
To make this permanent just add this into your /etc/network/interfaces:
auto eth0
iface eth0 inet static
offload-gso off
offload-gro off
offload-tso off
offload-rx off
offload-tx off
offload-rxvlan off
offload-txvlan off
offload-sg off
offload-ufo off
offload-lro off
Edit: Also make sure that ballooning is disabled for all VM’s and that you dont overprovision the RAM usage. That is the RAM configured for all VM’s guests + at least 2GB for the host itself shouldnt not be a sum larger than currently installed amount of RAM in that node.
Toutes de bonnes suggestions, mais cela fonctionnait parfaitement depuis un an, cela a paniqué aujourd’hui sur la version 6.14, et c’est redevenu normal après être revenu à la version 6.8.
La commande top ne montre aucun processus utilisant plus de 1 % du CPU, la charge moyenne dépasse 20 et indique un temps d’attente excessif. Mais seulement lors de l’exécution d’un noyau 6.14.
Oui, les pilotes de cartes réseau Intel fonctionnaient sans problème depuis des années et, soudainement, ces dernières semaines, il y a eu une tempête de merde dans le contrôle qualité chez Intel.
J’ai entendu parler des difficultés financières d’Intel et des récentes réductions d’effectifs. C’est une triste situation, mais j’ai reçu la carte réseau Intel à double port de cette machine d’Amazon en 2023.
Oui mais là il s’agit des pilotes logiciels, pas du matériel lui-même 🙂
Ah, oui, je suis d’accord.