Ubuntu 24.04 — blocages matériels (hard lockups) : collecter les preuves et isoler rapidement la cause

décembre 16, 2025 • février 3, 2026 • Lecture : 30 min • Views: 10

Cet article vous a aidé ?

Les hard lockups sont le pire type de « ça a gelé » car ils sont assez impolis pour emporter le noyau avec eux. Votre session SSH stagne, la console cesse de s’actualiser, et le seul élément encore réactif est le bouton d’alimentation. Vous redémarrez, et dmesg vous accueille par : “watchdog: BUG: hard LOCKUP”. Super. Et ensuite ?

Voici une approche de niveau production, axée sur les preuves, pour Ubuntu 24.04 : capturez les bons artefacts lors du prochain gel, réduisez rapidement l’espace de recherche et évitez les manips aléatoires qui rendent le problème indemonstrable.

Ce que signifie réellement un « hard lockup » (et ce que cela n’est pas)

Un « hard lockup » sous Linux, c’est le noyau qui admet qu’un cœur CPU a cessé de répondre aux interruptions pendant trop longtemps. La minuterie watchdog attend une activité périodique (typiquement un timer d’ordinaire prioritaire ou un NMI selon la configuration). Si un CPU est bloqué avec les interruptions désactivées, en train de tourner dans une boucle mauvaise, coincé dans le microcode/firmware, ou piégé dans un chemin de pilote défectueux, le watchdog s’alarme.

Ce que ce n’est pas : un message vague indiquant que « le système était lent ». Vous pouvez avoir une latence atroce, un iowait hors de contrôle, ou une machine surchargée sans hard lockups. Les hard lockups ressemblent davantage à « un CPU est parti déjeuner et n’a prévenu personne ».

Dans dmesg vous verrez généralement quelque chose comme :

watchdog: BUG: hard LOCKUP on cpu X
Parfois précédé de réinitialisations GPU, timeouts NVMe, stalls RCU, ou messages « NMI watchdog »
Parfois suivi de rien, parce que le système est trop figé pour logger

Les hard lockups peuvent être causés par :

Cas limites de gestion d’alimentation CPU (C-states, P-states, pilotes cpufreq)
Bugs de firmware/BIOS (tempêtes SMI, tables ACPI cassées, interactions microcode)
Pilotes de périphériques (GPU, HBA, NIC, modules hors-arbre)
Problèmes IOMMU/routage d’interruptions
Timeouts de firmware de stockage qui déclenchent des chemins noyau pathologiques
Instabilités thermiques/voltages (oui, parfois « c’est matériel » est la réponse)

Il existe un cousin : le « soft lockup ». C’est quand un CPU exécute du code noyau trop longtemps sans céder, mais les interruptions fonctionnent encore. Les soft lockups sont graves ; les hard lockups sont du niveau « appelez votre backup d’astreinte ».

Faits et petits rappels historiques utiles à 3h du matin

Fait 1 : Le détecteur de hard-lockup de Linux s’appuyait historiquement sur le NMI watchdog sur x86, car les NMI peuvent se déclencher même quand les interruptions normales sont désactivées.
Fait 2 : Les avertissements « RCU stall » apparaissent souvent près des gels, mais ce ne sont pas des hard lockups. Les stalls RCU signifient qu’un CPU n’atteint pas les états quiescents ; un hard lockup, c’est plus comme si le CPU cessait complètement de répondre.
Fait 3 : Les problèmes ACPI et SMI sont une source classique de comportements « tout se fige » depuis des décennies — surtout sur des firmwares fournisseurs optimisés pour la télémétrie Windows, pas pour la déterminisme Linux.
Fait 4 : La gestion des erreurs NVMe est devenue plus sophistiquée au fil des ans, mais les « reset storms » peuvent encore se propager en gel système si les interruptions et timeouts s’empilent mal.
Fait 5 : Les détecteurs de lockup du noyau sont volontairement prudents. Ils préfèrent vous importuner avec un avertissement plutôt que de rater un vrai CPU mort.
Fait 6 : Le détecteur de « hung task » du noyau est encore différent : il repère des tâches bloquées (souvent en attente d’I/O), pas des CPU morts. Les gens confondent ces outils constamment.
Fait 7 : Les travaux précoces sur le noyau « tickless » (NO_HZ) ont amélioré la consommation, mais ont aussi changé le comportement temporel ; certains bugs n’apparaissent qu’avec des combinaisons spécifiques timer/idle.
Fait 8 : Les mises à jour microcode peuvent corriger des lockups, mais aussi révéler des problèmes latents de pilotes ou firmware en changeant le timing. « Ça s’est empiré après les mises à jour » n’est pas automatiquement « la mise à jour a tout cassé ».

Une maxime fiabilité toujours valable : si vous ne pouvez pas le mesurer, vous ne pouvez pas le gérer. — W. Edwards Deming (paraphrasé)

Mode d’action pour un diagnostic rapide (premier/deuxième/troisième)

Voici la section « arrêtez de scroller, faites ceci maintenant ». L’objectif est de décider rapidement si vous avez affaire à : (a) un problème connu de pilote/firmware, (b) un cas limite de gestion d’alimentation, (c) une pathologie stockage/interruption, ou (d) du matériel défaillant.

Premier : confirmer que c’est bien un lockup et capturer les derniers mots

Récupérez les journaux du démarrage précédent (journal persistant) et cherchez les premiers messages précurseurs : réinitialisations NVMe, Xid GPU, assertions firmware iwlwifi, « irq X: nobody cared », « RCU stall », erreurs MCE.
Décidez si vous avez besoin d’un dump de crash. Si vous pouvez reproduire hebdomadairement ou plus fréquemment, vous avez besoin de kdump. Sinon vous passerez votre temps à débattre d’impressions.
Notez les versions du noyau et du firmware avant de toucher quoi que ce soit. Les mises à jour modifient le timing et peuvent « réparer » par hasard.

Second : isoler les coupables courants avec des basculements contrôlés

Modules hors-arbre et GPU : démarrez temporairement sans pilotes GPU propriétaires ou modules DKMS si c’est possible.
Gestion d’alimentation : essayez un changement à la fois : désactivez les C-states profonds (processor.max_cstate=1) ou désactivez intel_pstate (ou changez le governor). Ne lancez pas dix paramètres noyau en rafale.
IOMMU : basculez les réglages IOMMU si vous voyez des fautes DMA/IOMMU ou un comportement d’interruptions étrange.

Troisième : stressez le sous-système suspect et surveillez les compteurs

Stockage : lancez une charge I/O contrôlée et surveillez les compteurs d’erreurs NVMe, la latence et les réinitialisations.
CPU/thermique : vérifiez les logs MCE, les températures et le comportement des fréquences.
Interruptions : identifiez des tempêtes d’interruptions ou des IRQ coincés ; localisez quel appareil possède la ligne bruyante.

Blague #1 : Un hard lockup est la façon dont votre serveur demande un « exercice de cohésion d’équipe » entre le noyau et votre BIOS.

Préparer la capture d’éléments probants avant de tout changer

Quand les gens « déboguent » des lockups en bidouillant des options BIOS au hasard, en mettant à jour trois paquets, et en changeant des paramètres noyau tous en même temps, ils créent pire qu’un lockup : un lockup sans reproductibilité et sans surface de responsabilité.

Votre travail est de produire des artefacts qui survivent au reboot. Pour Ubuntu 24.04, l’essentiel est :

Journaux journald persistants entre les démarrages
Ring buffer du noyau du démarrage précédent (ou sortie netconsole)
Capture kdump (vmcore + dmesg) si la machine peut panique/rebooter
Journaux d’erreurs matérielles : MCE, EDAC, IPMI SEL (si serveur), journaux SMART/NVMe
Versions du firmware et du microcode
Un petit journal des changements testés et des modifications

Faire survivre les logs aux redémarrages (persistance journald)

Ubuntu par défaut a souvent des logs persistants sur les serveurs, mais pas toujours, et les conteneurs/VM peuvent être étranges. Rendre cela explicite :

cr0x@server:~$ sudo grep -R "^\s*Storage=" /etc/systemd/journald.conf /etc/systemd/journald.conf.d/* 2>/dev/null || true
...output...

Si vous ne voyez rien, définissez la persistance et redémarrez journald :

cr0x@server:~$ sudo install -d -m 2755 /etc/systemd/journald.conf.d
cr0x@server:~$ printf "[Journal]\nStorage=persistent\nSystemMaxUse=2G\n" | sudo tee /etc/systemd/journald.conf.d/persistent.conf
[Journal]
Storage=persistent
SystemMaxUse=2G
cr0x@server:~$ sudo systemctl restart systemd-journald

Décision : Si vos lockups sont peu fréquents, les logs persistants sont obligatoires. Si le disque est petit, limitez la taille ; ne désactivez pas la persistance.

Activer kdump (quand vous voulez des réponses, pas des suppositions)

Kdump est votre enregistreur de boîte noire. Il ne se déclenchera pas toujours sur un hard lockup (parce que le système peut être trop mort pour panique proprement), mais quand il le fait, c’est de l’or. Sur Ubuntu :

cr0x@server:~$ sudo apt-get update
cr0x@server:~$ sudo apt-get install -y linux-crashdump crash kexec-tools
...output...

Puis allouez de la mémoire crashkernel et activez :

cr0x@server:~$ sudo sed -n '1,200p' /etc/default/grub
...output...

Éditez pour inclure quelque chose comme crashkernel=512M sur un serveur typique (plus pour de grosses machines), puis :

cr0x@server:~$ sudo update-grub
...output...
cr0x@server:~$ sudo systemctl enable --now kdump-tools
...output...

Décision : Si vous pouvez tolérer la mémoire réservée, laissez kdump activé jusqu’à ce que la cause racine soit prouvée corrigée. Désactivez-le plus tard, pas maintenant.

Activer Magic SysRq (parfois on peut « débloquer » assez pour dumper l’état)

Les hard lockups ignorent souvent SysRq parce que les interruptions sont mortes sur le CPU affecté. Mais sur les systèmes SMP, un autre CPU peut encore fonctionner suffisamment longtemps pour que SysRq produise des backtraces.

cr0x@server:~$ cat /proc/sys/kernel/sysrq
176

Les valeurs varient ; 176 permet typiquement sync/remount/reboot et un peu de debug. Pour un plein accès :

cr0x@server:~$ echo 'kernel.sysrq = 1' | sudo tee /etc/sysctl.d/99-sysrq.conf
kernel.sysrq = 1
cr0x@server:~$ sudo sysctl -p /etc/sysctl.d/99-sysrq.conf
kernel.sysrq = 1

Décision : Activez SysRq temporairement sur les hôtes de débogage. En environnements très sécurisés, pesez la politique ; mais pour des incidents, les preuves l’emportent.

Envisager netconsole pour « la ligne de log juste avant la mort »

Quand les disques sont bloqués et la console locale figée, envoyer les messages du noyau par UDP vers une autre machine peut capturer le dernier souffle. C’est particulièrement utile pour les lockups liés au stockage et aux pilotes.

Tâches pratiques : commandes, sorties, décisions (12+)

Ce sont des tâches de terrain. Exécutez-les, lisez la sortie, puis prenez une décision. Chaque tâche est là parce qu’elle change ce que vous ferez ensuite.

Task 1: Confirm the exact kernel, build, and boot parameters

cr0x@server:~$ uname -a
Linux server 6.8.0-52-generic #53-Ubuntu SMP PREEMPT_DYNAMIC Fri Nov 15 12:34:56 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.0-52-generic root=UUID=... ro quiet splash

Ce que cela signifie : Vous avez besoin de la version exacte du noyau pour la corrélation avec des régressions connues et pour vérifier que les changements ont pris effet.

Décision : Si vous exécutez des noyaux HWE/edge ou des builds custom, notez-le. Ne mélangez pas « peut‑être que c’est le noyau » avec une origine inconnue.

Task 2: Pull previous-boot kernel logs (journal) and filter lockup signals

cr0x@server:~$ sudo journalctl -k -b -1 | egrep -i "hard LOCKUP|soft lockup|watchdog|RCU stall|NMI|hung task|MCE|IOMMU|nvme|AER|Xid|amdgpu|i915|EDAC" | tail -n 120
...output...

Ce que cela signifie : Vous cherchez des précurseurs : réinitialisations NVMe, spam AER PCIe, fautes GPU, exceptions machine check, fautes IOMMU.

Décision : Si vous voyez des erreurs matérielles (MCE/EDAC/AER), priorisez les pistes hardware/firmware avant les ajustements logiciels.

Task 3: Check if logs are persistent and sized sanely

cr0x@server:~$ journalctl --disk-usage
Archived and active journals take up 1.2G in the file system.

Ce que cela signifie : Si l’utilisation disque est faible et que vous redémarrez souvent, vous perdez peut-être de l’historique pertinent.

Décision : Augmentez SystemMaxUse si vous tronquez des démarrages plus anciens ; réduisez si vous êtes sur de petites racines.

Task 4: See how the previous shutdown looked (clean vs crash)

cr0x@server:~$ last -x | head -n 12
reboot   system boot  6.8.0-52-generic Mon Dec 29 09:18   still running
crash    system crash 6.8.0-52-generic Mon Dec 29 09:02 - 09:18  (00:16)
...output...

Ce que cela signifie : Les entrées « crash » indiquent souvent des réinitialisations abruptes ou des reboots watchdog.

Décision : Si vous avez des entrées crash sans logs, mettez en place netconsole et kdump pour en capter plus.

Task 5: Check hardware error logs (MCE on x86)

cr0x@server:~$ sudo journalctl -k | egrep -i "mce:|machine check|hardware error" | tail -n 80
...output...

Ce que cela signifie : Les Machine Check Exceptions indiquent des problèmes CPU/cache/mémoire/Niveau PCIe.

Décision : Si des MCE existent, cessez d’accuser des pilotes au hasard. Examinez le microcode, le BIOS, les DIMMs, la thermique et les cartes PCIe.

Task 6: Check EDAC (memory controller reporting) if present

cr0x@server:~$ sudo journalctl -k | egrep -i "EDAC|CE|UE|ecc" | tail -n 80
...output...

Ce que cela signifie : Les erreurs corrigées (CE) sont des alertes précoces ; les erreurs non corrigées (UE) peuvent provoquer un crash.

Décision : Toute UE est un incident. Reseat/remplacez les DIMMs, vérifiez la configuration mémoire et validez les réglages BIOS.

Task 7: Check PCIe AER errors (often points at a sick device or link)

cr0x@server:~$ sudo journalctl -k | egrep -i "AER:|pcieport|Corrected error|Uncorrected" | tail -n 120
...output...

Ce que cela signifie : Le spam d’AER corrigés peut toujours provoquer des tempêtes de latence et des comportements étranges des pilotes. Les non corrigés sont pires.

Décision : Identifiez le périphérique (BDF) et inspectez l’emplacement PCIe/la nappe/le riser/le firmware.

Task 8: NVMe health and error log (common in lockup-adjacent incidents)

cr0x@server:~$ sudo apt-get install -y nvme-cli
...output...
cr0x@server:~$ sudo nvme list
Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
/dev/nvme0n1     S6XXXXXXXXXXXX       ACME NVMe 1TB                              1         120.0  GB /   1.0  TB    512   B +  0 B   3B2QEXM7
cr0x@server:~$ sudo nvme smart-log /dev/nvme0
...output...
cr0x@server:~$ sudo nvme error-log /dev/nvme0 | head -n 40
...output...

Ce que cela signifie : Cherchez des erreurs média, une augmentation des entrées du log d’erreurs, des avertissements de température ou un nombre suspect de réinitialisations.

Décision : Si les compteurs d’erreurs augmentent, traitez d’abord comme un problème hardware/firmware : mettez à jour le firmware du SSD, changez d’emplacement, vérifiez l’alimentation PCIe et le refroidissement.

Task 9: Identify repeated storage timeouts/reset storms in the kernel log

cr0x@server:~$ sudo journalctl -k -b -1 | egrep -i "nvme.*timeout|resetting controller|I/O error|blk_update_request|Buffer I/O error|task abort" | tail -n 120
...output...

Ce que cela signifie : Les timeouts de stockage peuvent provoquer des blocages systémiques, surtout si le système de fichiers root ou le swap est impliqué.

Décision : Si des timeouts sont présents, arrêtez les « réglages ». Réparez le chemin de stockage : firmware, alimentation, link PCIe, câbles/backplanes, configuration multipath, paramètres de queue.

Task 10: Check interrupt distribution and spot a storm

cr0x@server:~$ head -n 30 /proc/interrupts
            CPU0       CPU1       CPU2       CPU3
  0:         22          0          0          0   IO-APIC   2-edge      timer
  1:          0          0          0          0   IO-APIC   1-edge      i8042
...output...
cr0x@server:~$ egrep -i "nvme|mlx|ixgbe|i40e|ena|nvidia|amdgpu|ahci|xhci" /proc/interrupts | head -n 20
...output...

Ce que cela signifie : Si un compteur IRQ monte en flèche sur un CPU, vous avez peut-être une tempête IRQ ou un déséquilibre d’affinité.

Décision : Si les interruptions sont épinglées sur un CPU, considérez l’état irqbalance, l’affinité manuelle, ou investiguez un périphérique/pilote défaillant.

Task 11: Confirm irqbalance behavior (don’t guess)

cr0x@server:~$ systemctl status irqbalance --no-pager
...output...

Ce que cela signifie : irqbalance peut aider sur des serveurs à usage général ; sur des machines faible-latence, il peut être volontairement désactivé.

Décision : Si désactivé, réactivez-le temporairement pour tester si les lockups corrèlent avec des hotspots d’interruptions. Si activé, envisagez d’épingler des IRQ critiques pour la reproductibilité.

Task 12: Check CPU frequency driver and governors (power management suspects)

cr0x@server:~$ sudo apt-get install -y linux-tools-common linux-tools-generic
...output...
cr0x@server:~$ cpupower frequency-info
...output...
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
intel_pstate

Ce que cela signifie : Différents pilotes cpufreq et governors peuvent modifier le timing et les transitions d’états d’alimentation qui déclenchent des lockups.

Décision : Si les lockups corrèlent avec des périodes d’inactivité, les états de veille profonds sont un suspect principal.

Task 13: Check idle state usage (C-states) if available

cr0x@server:~$ sudo apt-get install -y linux-tools-$(uname -r)
...output...
cr0x@server:~$ sudo turbostat --quiet --Summary --interval 5 --num_iterations 3
...output...

Ce que cela signifie : Si vous voyez le CPU passer beaucoup de temps dans des C-states profonds juste avant des lockups (difficile à attraper en direct, mais utile en test), vous avez une piste.

Décision : Testez en limitant les C-states via des paramètres noyau, un par un, et documentez.

Task 14: Check for GPU driver resets or Xid (workstations and compute nodes)

cr0x@server:~$ sudo journalctl -k -b -1 | egrep -i "NVRM|Xid|amdgpu|ring timeout|GPU reset|i915.*reset" | tail -n 120
...output...

Ce que cela signifie : Les hangs GPU peuvent figer la machine, surtout si le pilote GPU s’exécute en contexte noyau et se bloque.

Décision : Si des erreurs GPU précèdent les lockups, reproduisez sans le pilote GPU ou en le remplaçant (ouvert vs propriétaire) pour prouver la causalité.

Task 15: Confirm kdump is armed and where dumps would land

cr0x@server:~$ sudo systemctl status kdump-tools --no-pager
...output...
cr0x@server:~$ sudo kdump-config show
...output...

Ce que cela signifie : Si kdump n’est pas chargé ou crashkernel non réservé, vous n’aurez pas de vmcores.

Décision : Corrigez kdump maintenant, pas après le prochain incident.

Task 16: Force a controlled crash test (only on a test box or agreed maintenance)

cr0x@server:~$ echo 1 | sudo tee /proc/sys/kernel/sysrq
1
cr0x@server:~$ echo c | sudo tee /proc/sysrq-trigger
...output...

Ce que cela signifie : Le système devrait planter et redémarrer, produisant un vmcore si kdump est configuré.

Décision : Si aucun dump n’apparaît, tout votre plan « on déboguera plus tard » est fictif.

Réduire le périmètre par sous-système

1) Gestion d’alimentation : C-states, P-states, et le motif de lockup lié à l’inactivité

Beaucoup de hard lockups semblent « aléatoires » jusqu’à ce que vous les corréliez avec l’inactivité. Le système gèle la nuit, ou juste après une baisse de charge, ou pendant les périodes de faible trafic. C’est du domaine de la gestion d’alimentation : C-states profonds, package C-states, et transitions d’échelle de fréquence.

À surveiller :

Les lockups surviennent quand le système est principalement inactif
Pas d’erreurs I/O évidentes avant
Parfois corrigé en désactivant le sommeil profond dans le BIOS, ou en limitant les C-states via des paramètres noyau

Tests contrôlés (un changement à la fois) :

Limiter les C-states : processor.max_cstate=1 et/ou intel_idle.max_cstate=1 (Intel)
Désactiver le pilote idle spécifique : idle=poll (grosse brute ; utile en diagnostic)
Ajuster le mode intel_pstate (active/passive), ou définir le governor sur performance pour une fenêtre de test

Soyez strict : appliquez un paramètre par reboot et tenez un journal des changements. La tentation de coller tout un commentaire Reddit dans GRUB est forte. Résistez.

2) Firmware et BIOS : où le temps disparaît

Les bugs de firmware peuvent se manifester comme des lockups parce que le CPU disparaît dans le SMM (System Management Mode) trop longtemps, ou parce que les tables ACPI décrivent un comportement power/interruptions cassé. Linux ne peut pas corriger le firmware fournisseur. Il ne peut que contourner.

À vérifier :

Version BIOS/UEFI, notes de version (surtout les changements « stabilité » et « compatibilité PCIe »)
Package microcode installé et actif
Fonctions d’alimentation comme ASPM, Global C-states, « package C-state limit », et « Energy Efficient Turbo » (les noms varient)

Bonne pratique : mettez à jour BIOS et firmware périphérique tôt dans l’enquête, mais faites-le délibérément : changez une couche, puis observez pendant une fenêtre complète de reproduction.

3) Stockage et PCIe : NVMe, AER, et le piège « ce n’est pas l’I/O, c’est le bus »

Les lockups liés au stockage commencent souvent par des problèmes PCIe : liens marginals, NVMe qui surchauffe, alimentation PCIe insuffisante, firmware SSD bogué, ou un backplane qui fait des siennes. Le log noyau affichera souvent des timeouts et réinitialisations — si vous avez la chance de les capturer.

Signaux clés :

nvme nvme0: I/O X QID Y timeout
resetting controller en boucle
Spam PCIe AER corrigé/non corrigé pointant vers le BDF du NVMe
Systèmes de fichiers se plaignant (EXT4 journal aborts, XFS log I/O errors) après erreurs de périphérique

Décisions importantes :

Si le disque racine est sur le NVMe problématique et que vous voyez des réinitialisations, ne perdez pas de temps à « tuner l’I/O ». Stabilisez d’abord le chemin du périphérique.
Si des erreurs AER existent, traitez-les comme des preuves couche physique : emplacement, riser, backplane, firmware du périphérique, réglages PCIe BIOS.

4) GPU et piles d’affichage : quand le noyau est dommage collatéral

Sur les desktops Ubuntu, postes de travail dev, et nœuds de calcul, les hangs GPU sont des voisins fréquents des hard lockups. Un hang GPU peut déclencher une chaîne d’événements : réinitialisations de pilote, threads noyau bloqués, et parfois des rapports watchdog qui semblent liés au CPU mais ont commencé dans le chemin GPU.

Approche :

Vérifiez les messages de réinitialisation GPU juste avant le lockup
Essayez la pile pilote opposée (open vs propriétaire) pour une période de test
Réduisez la complexité : désactivez overclocks, désactivez fonctions d’économie d’énergie GPU, testez avec un workload plus simple (TTY) si possible

5) IOMMU et virtualisation : grand pouvoir, grande bizarrerie

Les problèmes IOMMU peuvent apparaître comme des fautes DMA, des réinitialisations de périphérique, ou des lockups. Les piles de virtualisation (KVM, VFIO passthrough) augmentent votre exposition : plus de périphériques, plus de routage d’interruptions, plus de cas limites.

Signaux :

DMAR: [DMA Read] fault ou logs de fautes AMD-Vi IOMMU
Lockups sous charge de passthrough
Comportement étrange des périphériques après suspend/resume (sur postes)

Tests contrôlés :

Basculez IOMMU : désactivez pour une fenêtre de test (intel_iommu=off ou amd_iommu=off) si la politique le permet
Ou activez le mode passthrough si vous avez besoin d’IOMMU mais voulez moins de translations : iommu=pt

6) Modules noyau : DKMS, pilotes tiers, et « ça marche sur mon laptop » en production

Les modules hors-arbre sont des suspects fréquents car ils ne reçoivent pas les mêmes tests de régression sur chaque mise à jour noyau. Ubuntu 24.04 exécute un noyau moderne ; c’est bon pour le support matériel, mais ça signifie aussi que les API évoluent et que le timing change.

Règle : Si vous avez des modules tiers, votre premier objectif diagnostique est de reproduire sans eux. Si vous ne pouvez pas, vous n’avez pas un bug ; vous avez une négociation de dépendance.

Blague #2 : La façon la plus rapide de reproduire un hard lockup est de programmer une démo pour la direction — les systèmes adorent un public.

Trois mini-histoires d’entreprise (ce que les équipes font mal)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

L’équipe gérait une flotte de serveurs Ubuntu traitant de la vidéo en arrière-plan. Ils ont commencé à voir des hard lockups hebdomadaires sur un sous-ensemble de matériel neuf. Le récit initial était confiant : « C’est le nouveau noyau. Revenons en arrière. » Ils ont figé la version du noyau sur la flotte et… les lockups ont continué. La confiance est restée ; les preuves, non.

Quelqu’un a finalement extrait les logs du démarrage précédent d’une machine qui avait journald persistant configuré (héros discret). Juste avant chaque gel se trouvaient des erreurs PCIe AER corrigées liées à un contrôleur NVMe spécifique. Personne n’avait regardé parce que le stockage « semblait OK » après le reboot.

L’hypothèse erronée était subtile : ils supposaient que les erreurs PCIe corrigées sont inoffensives. Elles ne le sont pas quand elles sont constantes. Les erreurs corrigées coûtent du temps ; elles corrèlent fortement avec des liens marginals et des échecs à venir.

La correction n’était pas un rollback du noyau. C’était une mise à jour de firmware du SSD et une mise à jour BIOS changeant les défauts de formation de lien PCIe. Ils ont aussi déplacé les disques hors d’un lot de backplanes particulier. Les lockups ont cessé. Le noyau a quand même été blâmé, parce que les noyaux sont des méchants pratiques.

Mini-histoire 2 : L’optimisation qui a échoué

Un service sensible à la latence voulait réduire la consommation au repos. Quelqu’un a activé des C-states package plus profonds dans le BIOS et changé le governor CPU vers un profil plus agressif d’économie d’énergie. Le service avait l’air parfait dans les graphes : moins de watts, latence p95 similaire en charge stable. Tout le monde s’est félicité d’être des adultes efficaces.

Puis sont apparus les lockups. Pas sous charge. Pendant les périodes calmes. Les machines gelaient tôt le matin quand le trafic chutait. Des hard lockups watchdog sont apparus dans dmesg après reboots forcés, mais rien d’évident ne les précédait.

Ils ont essayé l’habituel : mise à jour pilotes, noyau, même firmware NIC. Le tournant a été une expérience ennuyeuse : limiter les C-states via paramètres noyau pendant deux semaines sur un sous-ensemble d’hôtes, sans rien d’autre de changé. Les lockups ont disparu sur le groupe test et ont continué sur le groupe témoin.

L’« optimisation » était réelle, mais elle a poussé la plate-forme dans un cas limite firmware/idle. Ils ont annulé le changement BIOS C-state, documenté, et sont passés à autre chose. Les économies d’énergie étaient de toute façon moins importantes qu’un incident.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe gérant un cluster à charges mixtes (bases de données, caches, batch) avait une règle : chaque hôte doit avoir journaux persistants et kdump configurés, même si « ça gaspille de la RAM ». C’était impopulaire. Les gens se plaignaient de la RAM et de l’espace disque réservés. Le SRE qui l’a imposé était décrit comme « intensément pas drôle en soirée », ce qui, pour être juste, était exact.

Ils ont subi une série de hard lockups après une maintenance de routine. Certaines machines se sont complètement figées ; d’autres ont rebooté. Au lieu de débattre des causes possibles, ils ont extrait les vmcores des machines qui ont crashé proprement et comparé les backtraces. Plusieurs montraient un chemin commun impliquant une routine de récupération de pilote de stockage déclenchée par des timeouts répétés.

Ils n’ont pas eu besoin de reproduire aveuglément en production. Ils avaient des dumps, des horodatages et des précurseurs cohérents dans les logs. Le pilote vendor storage a été mis à jour, et le problème a été atténué par un paramètre de module spécifique en attendant la correction permanente.

Pas d’héroïsme. Pas de folklore. Juste la pratique ennuyeuse de collecter des preuves avant l’incident. Cette règle s’est remboursée en une semaine.

Erreurs courantes : symptôme → cause racine → correctif

Cette section est volontairement spécifique. Ce sont les modes d’échec que je vois sans cesse parce que les gens traitent « hard lockup » comme une malédiction Linux générique.

1) Symptom: Hard lockups mostly overnight or during low usage

Cause probable : État d’inactivité profond / bug C-state / firmware idle, parfois déclenché par le timing tickless et une faible activité d’interruptions.

Correctif : Testez en limitant les C-states avec processor.max_cstate=1 et/ou intel_idle.max_cstate=1. Si confirmé, ajustez les réglages BIOS/microcode, puis retirez la contournement noyau si possible.

2) Symptom: Hard lockup preceded by NVMe timeouts or controller resets

Cause probable : Problème de firmware NVMe, surchauffe, lien PCIe marginal, ou problèmes d’alimentation/backplane provoquant des reset storms.

Correctif : Mettez à jour le firmware du SSD et le BIOS. Vérifiez le refroidissement. Déplacez le disque sur un autre slot. Analysez les logs PCIe AER. Remplacez le périphérique si les compteurs d’erreurs augmentent.

3) Symptom: “RCU stall” spam and then lockup

Cause probable : Épuisement CPU (tempête d’interruptions, IRQ bloqué) ou chemin pilote désactivant les interruptions trop longtemps ; parfois un hôte VM sous pression d’interruptions.

Correctif : Vérifiez /proc/interrupts pour des tempêtes, confirmez irqbalance, identifiez le périphérique. Envisagez d’isoler des CPU ou de changer l’affinité IRQ. Corrigez le périphérique/pilote défaillant.

4) Symptom: Hard lockups after installing proprietary GPU driver

Cause probable : Hang du pilote GPU ou boucle de reset ; le noyau bloqué dans un chemin de pilote.

Correctif : Reproduisez avec le pilote ouvert ou sans accélération GPU. Mettez à jour le pilote et le noyau dans une matrice contrôlée. Sur un poste, réduisez temporairement les fonctions de gestion d’énergie GPU.

5) Symptom: Lockups started after enabling virtualization passthrough

Cause probable : Problèmes de traduction IOMMU/remapping d’interruptions, firmware périphérique défaillant sous VFIO, ou ACS/ routage d’interruptions buggy.

Correctif : Vérifiez les logs de fautes IOMMU. Testez iommu=pt ou désactivez temporairement IOMMU. Mettez à jour BIOS et firmware périphérique. Évitez d’empiler plusieurs paramètres noyau expérimentaux en même temps.

6) Symptom: “It’s always CPU X” in watchdog messages

Cause probable : Hotspot d’affinité IRQ, réglages d’isolation CPU, ou un problème matériel spécifique au cœur CPU (rare mais réel).

Correctif : Inspectez la distribution IRQ et le pinning CPU. Si cela suit vraiment le cœur à travers les configurations, envisagez des diagnostics matériels et l’échange CPU/carte si possible.

7) Symptom: No logs at all right before the freeze

Cause probable : Les logs ne sont pas persistants, ring buffer écrasé, ou le lockup est si brutal qu’il empêche immédiatement l’écriture des logs.

Correctif : Activez journald persistant, activez kdump, et envisagez netconsole. Augmentez aussi le buffer de logs du noyau si nécessaire pour les boots bruyants.

Listes de contrôle / plan étape par étape

Checklist A: Evidence capture (do this once, then leave it alone)

Activez le stockage persistant journald avec un plafond raisonnable.
Installez et configurez kdump ; vérifiez avec un crash test contrôlé (en maintenance).
Enregistrez : version du noyau, cmdline, version BIOS, version microcode, versions majeures des pilotes (GPU, NIC, HBA stockage).
Assurez la synchronisation temporelle (chrony/systemd-timesyncd). De mauvais horodatages ruinent les corrélations.
Si les logs disparaissent encore, configurez netconsole vers une machine collectrice.

Checklist B: Fast narrowing plan (one variable per reboot)

Retirez les modules tiers (ou démarrez un noyau propre connu) et ouvrez une fenêtre de reproduction.
Test gestion d’alimentation : limitez les C-states pour une fenêtre. Si cela s’améliore, pivotez vers l’enquête BIOS/microcode.
Test chemin stockage : vérifiez SMART/logs NVMe et PCIe AER ; stressez l’I/O en surveillant les logs.
Test IOMMU si des fautes existent ou si le passthrough est utilisé : iommu=pt ou désactivez pour test (si la politique le permet).
Test interruptions : vérifiez /proc/interrupts avant et après charge ; cherchez des tempêtes et problèmes d’affinité.

Checklist C: If you must mitigate now (production triage)

Appliquez la mitigation la moins invasive qui cible plausiblement le sous-système impliqué par les logs.
Privilégiez des mitigations réversibles et mesurables (paramètres noyau, figer la version d’un pilote) plutôt que des pêches BIOS hasardeuses.
Si des erreurs de stockage existent : migrez la charge hors de l’hôte ; ne « regardez pas en attendant ».
Si des erreurs MCE/EDAC existent : retirez l’hôte du service et lancez des diagnostics matériels ; ne cherchez pas à optimiser autour d’un DIMM flaky.

FAQ

1) What’s the difference between a soft lockup and a hard lockup?

Soft lockup : un CPU est coincé à exécuter du code noyau trop longtemps sans ordonnancer ; les interruptions fonctionnent encore. Hard lockup : un CPU cesse de répondre aux interruptions assez longtemps pour que le watchdog se déclenche. Le hard est généralement plus sévère et indique plutôt des chemins désactivant les interruptions, des problèmes de firmware ou du matériel.

2) If I see “hard LOCKUP” once, is the machine unreliable forever?

Non. Certains lockups sont des régressions ou des bugs firmware qui se corrigent. Mais traitez-le comme un signal sérieux jusqu’à avoir une reproduction propre et un correctif vérifié. « Ça a disparu » n’est pas une correction ; c’est une pause.

3) Does kdump always work for hard lockups?

Non. Si le système est totalement bloqué et ne peut pas déclencher de panic, vous n’aurez peut-être pas de dump. C’est pourquoi les journaux persistants et parfois netconsole sont importants. Kdump reste utile car quand il fonctionne, il raccourcit énormément les enquêtes.

4) Should I disable the watchdog to stop the messages?

Ne le désactivez pas comme « correctif ». Au mieux vous cachez le symptôme ; au pire vous transformez une défaillance détectable en un blocage silencieux qui ressemble à « le réseau est mort ». Laissez les watchdogs actifs pendant le débogage.

5) Can storage issues really cause CPU hard lockups?

Indirectement, oui. Les timeouts, reset storms et les traitements d’erreurs pathologiques peuvent conduire à des conditions où les CPU passent trop de temps dans des sections critiques ou cessent de servir correctement les interruptions. De plus, des fautes au niveau PCIe peuvent affecter le comportement système au-delà du simple I/O.

6) What’s the fastest single change to test idle-state-related lockups?

Limitez les C-states pour une fenêtre de test : ajoutez processor.max_cstate=1 (et sur Intel aussi intel_idle.max_cstate=1) à la ligne de commande du noyau. C’est brutal, mais c’est un toggle diagnostique propre.

7) I only see the lockup message after reboot. How do I catch the cause before it freezes?

Les journaux persistants aident. Netconsole peut capturer les derniers messages noyau vers un autre hôte. Si le système fonctionne encore sur certains CPU pendant le gel, les backtraces SysRq peuvent se dumper dans les logs. Et si vous pouvez panique sur hang (prudemment), kdump peut capturer l’état.

8) Is this more likely on bare metal than VMs?

Les hard lockups sont plus fréquents sur le bare metal car vous êtes exposé au firmware, à la gestion d’énergie, et aux pilotes directement. Les VMs peuvent encore rencontrer des soft lockups et des stalls, mais l’hyperviseur absorbe souvent certaines classes d’anomalies matérielles.

9) What if the lockups started exactly after upgrading to Ubuntu 24.04?

Alors votre priorité est de corréler avec : changements de version du noyau, modifications de la pile de pilotes (notamment GPU/NIC/stockage), et valeurs par défaut de gestion d’énergie. Capturez d’abord les preuves, puis testez : noyau plus ancien sur 24.04, ou noyau 24.04 sur ancien userspace si vous avez un labo. Évitez de changer le BIOS en même temps que l’OS sauf si vous pouvez isoler les variables.

10) When do I stop debugging and replace hardware?

Quand vous avez des erreurs MCE/EDAC, des compteurs NVMe en hausse, du spam PCIe AER persistant lié à un périphérique, ou si le problème suit un composant à travers des changements OS. Le matériel a le droit d’être coupable.

Conclusion : étapes pratiques suivantes

Les hard lockups donnent l’impression du chaos parce qu’ils volent votre observabilité au pire moment. Votre contre-mesure est une capture de preuves disciplinée et des expériences contrôlées.

Activez journald persistant et vérifiez que vous pouvez lire les logs noyau du démarrage précédent.
Configurez kdump et lancez un crash test contrôlé pendant la maintenance. Si vous ne pouvez pas obtenir de vmcore, ne faites pas semblant.
Au prochain incident, extrayez les précurseurs depuis journalctl -k -b -1 et classez le problème : gestion d’alimentation, stockage/PCIe, GPU/pilote, IOMMU/interruptions, ou erreurs matérielles.
Faites un changement par reboot. Tenez un petit journal des modifications. Oui, même si vous détestez la paperasse.
Si vous voyez des erreurs MCE/EDAC/AER/NVMe : arrêtez de tuner et commencez à réparer le chemin physique — firmware, refroidissement, emplacements, et pièces.

Si vous faites cela correctement, l’investigation devient ennuyeuse. L’ennui, c’est bon. L’ennui signifie que vous transformez un système hanté en un système mesurable.