Blocages aléatoires sans BSOD : le journal qui révèle le coupable

février 17, 2026 • février 17, 2026 • Lecture : 27 min • Views: 0

Cet article vous a aidé ?

Vous connaissez ce type de « blocage ». La souris s’arrête. Le son boucle comme une cassette hantée. Caps Lock ne bascule plus. Pas d’écran bleu. Pas de dump. Juste une machine qui a décidé silencieusement de prendre un jour de congé.

Quand les gens disent « aléatoire », j’entends « nous n’avons pas regardé au bon endroit ». Le bon endroit n’est généralement pas votre pilote GPU, pas votre RAM (même si parfois oui), et pas l’optimiseur qui promettait d’« améliorer les performances ». Le bon endroit est le journal qui enregistre les timeouts et réinitialisations de stockage : le moment où le système a essayé de lire ou d’écrire et que le périphérique… n’a pas répondu à temps.

Le journal coupable : où les blocages laissent réellement des empreintes

Les blocages durs sans BSOD sont souvent imputés au « graphique » parce que c’est visible. Mais ce que vous voyez n’est que la façade. L’arrière-cour, c’est l’I/O : stockage, liens PCIe, firmware des contrôleurs et décisions de gestion d’alimentation qui semblaient géniales sur une diapositive.

Le « journal unique » qui révèle régulièrement le coupable est celui qui enregistre les timeouts et réinitialisations de stockage :

Windows : Event Viewer → System log, en particulier les événements StorPort, stornvme, disk et WHEA-Logger autour du blocage. Les classiques : Event ID 129 (« Reset to device, \Device\RaidPortX, was issued ») et Event ID 153 (opération I/O retentée).
Linux : buffer du noyau : dmesg / journalctl -k, en particulier les messages comme blk_update_request: I/O error, timed out, nvme ... controller is down; will reset, resetting controller, ataX: hard resetting link et les avertissements de système de fichiers.

Pourquoi cela fonctionne : les piles de stockage sont prudentes. Quand l’OS ne reçoit pas de réponse du dispositif, il le consigne. Même quand tout le reste est bloqué. Même quand l’interface est morte. Même quand le système « récupère » et que vous pensez que rien ne s’est passé.

Le blocage est souvent le symptôme visible d’un noyau qui attend une I/O dans un état non interruptible (D-state sous Linux) ou d’un pilote de port de stockage Windows qui essaie des réinitialisations et des reprises pendant que votre bureau cesse poliment de fonctionner.

Une citation à afficher sur votre écran :

John Allspaw : « L’échec est une partie normale des systèmes complexes. » (idée paraphrasée)

Ce qu’est réellement un « blocage sans BSOD » au niveau du système

Un BSOD est un arrêt contrôlé : l’OS identifie une condition irrécupérable et arrête avec un dump. Un blocage est pire d’une autre manière : l’OS est toujours « vivant », mais le progrès s’arrête parce qu’un thread critique est bloqué, une tempête d’interruptions se produit, ou le système est coincé à un niveau où il ne peut pas planifier le travail nécessaire pour récupérer.

En pratique, la plupart des « blocages aléatoires » se classent en quelques catégories :

1) Timeouts I/O de stockage et réinitialisations de contrôleur

C’est la grosse cause. Les périphériques NVMe peuvent se bloquer, les liaisons SATA peuvent osciller, les stockages USB peuvent subir des chutes de tension, le firmware RAID/HBA peut se mettre en pause, et les états d’alimentation des contrôleurs peuvent mal se comporter. L’OS effectue alors des reprises, des réinitialisations et des attentes. Pendant ce temps, tout ce qui touche le disque affecté s’arrête. Si le disque est votre lecteur système, félicitations : tout y touche.

2) Cas limites PCIe / gestion d’alimentation

ASPM, états L1, politiques d’inactivité agressives et combinaisons de firmware boguées peuvent provoquer un comportement du type « fonctionne pendant des jours, puis se fige dans un timing exact ». Ce n’est pas mystique. C’est une machine d’états avec une mauvaise transition.

3) Instabilité mémoire et processeur

RAM défectueuse, overclocks instables, undervolting ou alimentations marginales peuvent geler une machine sans laisser de journaux propres. Mais même alors, les journaux de stockage montrent souvent des « timeouts » parce que le CPU a cessé de traiter les interruptions. Cela ne veut pas dire que le stockage a causé le problème — mais cela indique où le système a cessé de répondre.

4) Blocages liés au système de fichiers / intégrité

Les systèmes de fichiers peuvent se bloquer en attendant la complétion d’écritures ou des commits de journal. ZFS peut se bloquer dans TXG sync si le périphérique sous-jacent se comporte mal. NTFS peut sembler « correct » alors que le stockage en dessous ne l’est pas.

Blague n°1 : Un « blocage aléatoire » n’est jamais aléatoire ; c’est juste votre ordinateur qui refuse de rédiger un rapport d’incident détaillé.

Faits intéressants et contexte historique (court et utile)

StorPort existe parce que le stockage est compliqué. Microsoft a introduit StorPort pour remplacer SCSIport, afin de supporter des performances supérieures et les architectures de stockage modernes.
Event ID 129 est une réinitialisation, pas un diagnostic. Il indique que l’OS a forcé une réinitialisation parce que le périphérique n’a pas répondu ; le « pourquoi » se trouve ailleurs (alimentation, firmware, câblage, PCIe).
NVMe a apporté des performances et de nouveaux modes de défaillance. NVMe est un protocole à files d’attente sur PCIe, ce qui signifie que les états d’alimentation du lien et le timing du firmware comptent plus que beaucoup ne l’imaginent.
Les messages « link reset » ATA/SATA existent depuis des décennies. Le logging Linux comme « hard resetting link » est l’équivalent moderne de « le câble ou le contrôleur a un moment. »
Les SSD grand public sont optimisés pour les benchmarks, pas pour la latence tail en pire cas. Un disque peut obtenir d’excellents scores et pourtant geler un système quand la collecte des déchets intervient au mauvais moment.
Les politiques de cache d’écriture ont longtemps été des pièges. Depuis les premiers jours de l’IDE jusqu’au NVMe moderne, « activer le cache d’écriture » a amélioré le débit tout en augmentant parfois le rayon d’impact des pertes d’alimentation ou des bugs firmware.
SMART a été conçu pour la prédiction, pas pour l’absolu. Les disques peuvent tomber en panne avec un SMART parfait, et d’autres peuvent traîner avec des compteurs effrayants. Utilisez SMART comme indice, pas comme verdict.
Les journaux du noyau sont souvent la dernière chose qui fonctionne. Même quand l’espace utilisateur est gelé, le noyau peut encore consigner des reprises et des réinitialisations dans le ring buffer, qui survit jusqu’au redémarrage.
Les équipes de stockage entreprise parlent plus de « tail latency » que de débit. C’est le 99,9e percentile des stalls I/O qui rend les systèmes confus, pas la moyenne en MB/s.

Feuille de route de diagnostic rapide (premier/deuxième/troisième)

C’est le chemin le plus court que je connaisse de « ma machine se fige » à « je peux pointer le sous-système responsable ». Suivez-le dans l’ordre. Ne faites pas de freestyle.

Premier : établir si l’I/O de stockage a stallé au moment du blocage

Windows : recherchez des événements dans le journal System (StorPort/stornvme/disk) dans les minutes autour du blocage et au démarrage après l’arrêt forcé.
Linux : vérifiez journalctl -k -b -1 (boot précédent) pour des timeouts, réinitialisations et erreurs de système de fichiers.

Si vous voyez des réinitialisations/timeouts, considérez la stabilité du chemin de stockage comme suspecte jusqu’à preuve du contraire.

Second : corréler avec la topologie matérielle et la gestion d’alimentation

Identifiez si le périphérique affecté est NVMe sur PCIe, SATA, USB, ou derrière un RAID/HBA.
Vérifiez les réglages de lien/power (Windows PCI Express Link State Power Management ; Linux ASPM).
Vérifiez les versions de firmware (SSD, BIOS/UEFI) et les pilotes (chipset/stockage).

Troisième : reproduire sous charge contrôlée et mesurer la latence tail

Utilisez fio sur Linux ou un outil comparable pour générer un I/O mix soutenu et surveiller les erreurs/timeouts.
Surveillez les distributions de latence (iostat -x, nvme smart-log, compteurs PerfMon sous Windows).

Si vous pouvez déclencher le blocage avec une charge I/O, vous venez de transformer « aléatoire » en « diagnostiquable ». Voilà la victoire.

Tâches pratiques : commandes, sorties attendues et la décision que vous prenez

Ci‑dessous des tâches pratiques. Chacune inclut une commande, une sortie d’exemple, ce que cela signifie, et la décision suivante. Les commandes sont affichées au format shell Linux ; si vous êtes sous Windows, l’équivalent est « Event Viewer + PowerShell ». Je vous donne les commandes Linux parce qu’elles sont précises et reproductibles, et parce que beaucoup de blocages « postes Windows » sont finalement des problèmes « firmware + NVMe » qui apparaissent identiquement sur un live média Linux.

Task 1: Check the previous boot’s kernel log for timeouts

cr0x@server:~$ journalctl -k -b -1 | egrep -i 'timeout|reset|nvme|ata|i/o error|blk_update_request|hung'
Jan 12 09:41:02 host kernel: nvme nvme0: I/O 123 QID 7 timeout, aborting
Jan 12 09:41:02 host kernel: nvme nvme0: controller is down; will reset: CSTS=0x3
Jan 12 09:41:03 host kernel: blk_update_request: I/O error, dev nvme0n1, sector 1953525168

Ce que cela signifie : Le noyau a émis une I/O, n’a pas obtenu de complétion et a réinitialisé le contrôleur. Ce n’est pas normal. Un événement isolé peut arriver ; des répétitions constituent un motif.

Décision : Considérez NVMe/contrôleur/power management PCIe comme suspects principaux. Poursuivez par vérification santé NVMe et liens PCIe. Planifiez aussi une mise à jour de firmware.

Task 2: Identify whether processes were stuck in uninterruptible I/O (D-state)

cr0x@server:~$ ps -eo state,pid,comm,wchan:32 | awk '$1 ~ /D/ {print}' | head
D  1423  postgres         nvme_poll
D  2210  jbd2/nvme0n1-8   __flush_work

Ce que cela signifie : Les processus en D-state attendent une I/O. Quand suffisamment de threads critiques passent en D-state, le système paraît gelé.

Décision : Concentrez-vous sur le périphérique de stockage à l’origine de ces attentes (ici : nvme0n1). Ne perdez pas des heures sur le dépannage UI/bureau.

Task 3: Check block layer and device errors in dmesg (current boot)

cr0x@server:~$ dmesg -T | egrep -i 'nvme|ata|I/O error|resetting|link is down|frozen|AER' | tail -n 30
[Mon Jan 13 10:12:44 2026] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
[Mon Jan 13 10:12:44 2026] nvme 0000:01:00.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer
[Mon Jan 13 10:12:44 2026] nvme nvme0: controller reset

Ce que cela signifie : Des erreurs PCIe (même « Corrected ») plus des réinitialisations de contrôleur sont un signal. Les problèmes de couche physique peuvent venir de l’alimentation, de l’intégrité du signal, du firmware, ou des transitions d’état ASPM.

Décision : Vérifiez le statut du lien PCIe et l’ASPM ; envisagez une mise à jour du BIOS, reseater le périphérique, tester un autre slot (desktop) ou un autre chemin backplane/câble (serveur).

Task 4: Inspect PCIe link speed/width and error counters

cr0x@server:~$ sudo lspci -vv -s 01:00.0 | egrep -i 'LnkCap|LnkSta|ASPM|AER|DevSta' -n
45:        LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <8us
47:        LnkSta: Speed 16GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
63:        DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-

Ce que cela signifie : Le lien est négocié à pleine vitesse/largeur, mais CorrErr+ indique que des erreurs corrigées sont survenues. Pas automatiquement fatal, mais corrélé aux blocages c’est exploitable.

Décision : Si les erreurs augmentent avec le temps, testez avec ASPM désactivé et/ou une vitesse de lien inférieure (paramètre BIOS) pour confirmer la stabilité. Si c’est stable, vous avez trouvé l’axe de défaillance.

Task 5: Check NVMe SMART/health and error log

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 45 C
available_spare                     : 100%
percentage_used                     : 7%
media_errors                        : 12
num_err_log_entries                 : 98

Ce que cela signifie : media_errors et la hausse de num_err_log_entries ne sont pas « normales ». Même si le disque « fonctionne », il indique qu’il a des difficultés.

Décision : Sauvegardez immédiatement, planifiez un remplacement ou une mise à jour de firmware. Si c’est le disque système d’un portable/desktop : traitez-le comme urgent, pas comme « pour plus tard ».

Task 6: Check NVMe controller error log for timeouts/resets

cr0x@server:~$ sudo nvme error-log /dev/nvme0 | head -n 20
Error Log Entries for device:nvme0 entries:64
 Entry[ 0]
  error_count     : 98
  sqid            : 7
  cmdid           : 0x0012
  status_field    : 0x4004
  parm_error_loc  : 0x0000
  lba             : 1953525168

Ce que cela signifie : Le disque a enregistré des erreurs liées à des commandes/queues. Cela complète les timeouts du noyau. Ensemble ils racontent une histoire : « L’OS a demandé, le disque n’a pas répondu correctement. »

Décision : Confirmez la version du firmware et vérifiez si votre plateforme a des problèmes connus avec APST/ASPM. Si vous pouvez reproduire, désactivez APST pour tester.

Task 7: On SATA systems, check SMART for reallocated/pending sectors

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i 'Reallocated_Sector_Ct|Current_Pending_Sector|UDMA_CRC_Error_Count|Power_On_Hours'
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       12
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       3
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       45
  9 Power_On_Hours          0x0032   093   093   000    Old_age   Always       -       18765

Ce que cela signifie : Les secteurs en attente et les erreurs CRC sont du carburant classique pour « blocages et reprises ». Les erreurs CRC impliquent souvent le câblage/backplane ; les secteurs en attente impliquent la surface du disque ou la couche de traduction flash.

Décision : Si UDMA_CRC_Error_Count augmente, remplacez d’abord le câble/le chemin backplane. Si des secteurs pending existent, planifiez le remplacement du disque.

Task 8: Check filesystem for corruption signals after forced reboots

cr0x@server:~$ journalctl -b | egrep -i 'EXT4-fs error|xfs_repair|I/O error|journal|buffer i/o error' | tail
Jan 13 10:18:11 host kernel: EXT4-fs warning (device nvme0n1p2): ext4_end_bio:345: I/O error 10 writing to inode 262402 starting block 12345678)

Ce que cela signifie : Le système de fichiers se plaint d’écritures échouées. C’est un dommage en aval du problème I/O, pas la cause racine.

Décision : Stabilisez d’abord le chemin de stockage. Ensuite lancez les vérifications appropriées du système de fichiers pendant une fenêtre de maintenance (et après confirmation des sauvegardes).

Task 9: Measure tail latency and saturation with iostat

cr0x@server:~$ iostat -x 1 5
Linux 6.5.0 (host) 	01/13/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          2.10    0.00    1.20   35.40    0.00   61.30

Device            r/s     w/s   r_await   w_await  aqu-sz  %util
nvme0n1         120.0   300.0     3.20   220.50   18.40  99.80

Ce que cela signifie : w_await à 220 ms avec %util ~100% est un générateur de stalls. Votre système « se fige » parce que tout attend derrière ces écritures.

Décision : Déterminez si c’est une saturation attendue de la charge (besoin de stockage plus rapide / plus de profondeur de file / répartition différente) ou une latence pathologique (firmware, GC, erreurs). Si les pics de latence corrèlent avec des réinitialisations/erreurs, c’est pathologique.

Task 10: Reproduce under controlled I/O with fio (without destroying data)

cr0x@server:~$ fio --name=latcheck --filename=/var/tmp/fio.test --size=2G --direct=1 --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=1 --time_based --runtime=120 --group_reporting
latcheck: (groupid=0, jobs=1): err= 0: pid=3210: Mon Jan 13 10:30:10 2026
  read: IOPS=12.3k, BW=48.0MiB/s (50.3MB/s)
    slat (usec): min=4, max=420, avg=12.5, stdev=5.3
    clat (usec): min=75, max=850000, avg=240.1, stdev=9200.4
  write: IOPS=5, BW=20.0KiB/s
    clat (msec): min=2, max=12000, avg=980.0, stdev=2100.0

Ce que cela signifie : La latence de complétion maximale atteignant des secondes (ou pire) est l’endroit où le « blocage » existe. Notez aussi l’effondrement du débit d’écriture — souvent signe d’un housekeeping interne du disque ou d’un problème.

Décision : Si fio peut déclencher le stall, vous avez un test reproductible. Utilisez‑le pour valider les correctifs (mise à jour firmware, réglages d’alimentation, pilote différent) et pour justifier un remplacement.

Task 11: Check ZFS-specific stalls (if you run ZFS)

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          nvme0n1   ONLINE       0     3     0

errors: Permanent errors have been detected in the following files:
        /tank/vmstore/guest01.img

Ce que cela signifie : ZFS indique avoir détecté des erreurs d’écriture ; cela s’aligne avec les blocages. Le « fichier avec erreurs » est la victime.

Décision : Remplacez/réparez le périphérique ou le chemin sous-jacent. Lancez un scrub après rétablissement de la stabilité. Si c’est un pool sur disque unique, admettez que vous avez besoin de redondance si vous tenez à vos week‑ends.

Task 12: Check for kernel soft lockups and RCU stalls (CPU not making progress)

cr0x@server:~$ journalctl -k -b | egrep -i 'soft lockup|hard lockup|RCU stall|watchdog' | tail
Jan 13 10:14:22 host kernel: watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [kworker/u32:1:842]

Ce que cela signifie : Le CPU n’a pas été planifié normalement pendant longtemps. Cela peut être causé par des pilotes en boucle, des tempêtes d’interruptions, ou des problèmes matériels. Les timeouts de stockage peuvent être cause et effet simultanément.

Décision : Si les soft lockups corrèlent avec PCIe/AER ou réinitialisations NVMe, suspectez la plateforme/firmware/gestion d’alimentation. S’ils apparaissent seuls, élargissez la recherche à la stabilité CPU/RAM.

Task 13: Test whether ASPM is enabled (common NVMe freeze contributor)

cr0x@server:~$ cat /sys/module/pcie_aspm/parameters/policy
powersave

Ce que cela signifie : Le système gère activement les états d’alimentation PCIe de façon agressive.

Décision : Pour le diagnostic, passez en mode performance (ou désactivez ASPM) et voyez si les blocages cessent. Si c’est le cas, vous avez trouvé un contournement stable et un problème de compatibilité/firmware à corriger proprement.

Task 14: Confirm whether NVMe APST is active (Linux)

cr0x@server:~$ cat /sys/module/nvme_core/parameters/default_ps_max_latency_us
25000

Ce que cela signifie : La politique APST (Autonomous Power State Transition) est active. Certains disques/plateformes se comportent mal sous certains budgets de latence.

Décision : Pour tester, définissez une politique plus conservatrice via un paramètre noyau dans le chargeur de démarrage (par ex. nvme_core.default_ps_max_latency_us=0) et voyez si le problème disparaît. Si oui, cherchez des mises à jour firmware ou laissez ce réglage comme correctif pragmatique.

Blague n°2 : Le firmware de stockage, c’est comme le café de bureau — généralement correct, parfois catastrophique, et jamais amélioré en faisant semblant de ne pas exister.

Trois mini-histoires en entreprise depuis le terrain

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

Une entreprise de taille moyenne exploitait une flotte de postes Windows pour la CAO et le traitement de données. Les utilisateurs signalaient des « blocages aléatoires » plusieurs fois par semaine. Le service IT a traqué les pilotes GPU parce que les blocages survenaient en faisant tourner des modèles ou en déplaçant des fenêtres. L’hypothèse de travail était : « si l’écran s’arrête, c’est la carte graphique. »

L’équipe a remplacé quelques GPU. Ils ont réinstallé des machines. Ils ont même accusé une mise à jour Windows. Le problème persistait, et le seul détail constant était l’absence de BSOD. La direction a qualifié cela d’« erreur utilisateur » comme seule la direction sait le faire.

Lors d’une semaine particulièrement mauvaise, quelqu’un a finalement vérifié le journal System juste après un blocage et un redémarrage forcé. Les mêmes deux événements revenaient : réinitialisations StorPort (ID 129) et événements de reprise disque (ID 153). Ils étaient regroupés autour du moment du blocage.

L’erreur n’était pas « les pilotes GPU ne causent jamais de blocages ». Ils peuvent. L’erreur était de traiter le symptôme visible comme la frontière du sous‑système. Une fois que l’équipe a pivoté vers le stockage, le motif est apparu : un modèle NVMe particulier + une révision BIOS de portable spécifique + une gestion d’alimentation du lien agressive. Une mise à jour du BIOS et un changement de politique d’alimentation ont arrêté les blocages, et les cas restants ont reçu des mises à jour firmware SSD.

La leçon : considérez le journal des timeouts de stockage comme le premier intervenant. C’est lui qui montre où l’OS a cessé de faire confiance à un périphérique, pas où l’utilisateur a cessé de faire confiance à l’ordinateur.

Mini-histoire 2 : L’optimisation qui s’est retournée

Une société de services avait un appliance d’analyse Linux expédiée aux clients. Pour gagner en performance, un ingénieur a activé des économies d’énergie plus profondes dans le BIOS et peaufiné l’OS pour réduire l’inactivité. En labo, tout allait bien : les benchmarks étaient bons, les températures en baisse, tout le monde se sentait responsable.

Sur le terrain, les appareils ont commencé à « se figer » pendant les jobs de nuit. Pas de journaux de panique, pas de crash propre. Juste la nécessité d’un hard power-cycle. Les jobs écrivaient beaucoup sur un espace scratch NVMe local.

La première réaction a été d’optimiser la charge : moins de fsync, tampons plus grands, plus de concurrence. Cela a empiré. La latence tail a augmenté, et les systèmes sont devenus plus fragiles. Plus ils « optimisaient », plus ils poussaient le périphérique dans l’état exact où il cessait de répondre et nécessitait une réinitialisation du contrôleur.

Quand quelqu’un a finalement récupéré les logs du noyau du boot précédent, l’histoire était bruyante : timeouts NVMe, réinitialisations contrôleur, et erreurs PCIe corrected occasionnelles. L’« optimisation » avait poussé la plateforme dans un cas limite d’état d’alimentation sous I/O soutenu. Le correctif a été ennuyeux : désactiver l’état d’alimentation problématique (combinaison ASPM/APST) et déployer une mise à jour firmware. Les performances ont à peine changé, mais la stabilité est revenue.

Une optimisation qui se retourne est courante car elle change le timing. Et le timing, c’est là que vivent les bugs firmware.

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

Une petite équipe d’infra gérait des charges mixtes : un cluster virtualisé plus quelques nœuds DB bare‑metal. Ils avaient une règle stricte et peu glamour : chaque hôte collectait et conservait les logs kernel/system après les redémarrages, et chaque ticket d’incident exigeait la pièce jointe des logs du dernier boot.

Un nœud DB a commencé à « se figer » une fois toutes les deux semaines. La panne était courte (quelqu’un le re‑mettais sous tension), mais l’impact business était élevé car il hébergeait un système interne critique. Les premiers incidents ont été attribués au « Linux qui fait des siennes ». Ce n’est pas un diagnostic ; c’est une reddition.

Parce que les logs étaient conservés, l’équipe a pu comparer plusieurs incidents. À chaque fois, le même motif apparaissait : augmentation des erreurs CRC SATA suivie d’une réinitialisation de lien et d’un long stall I/O. SMART n’affichait pas de secteurs réalloués, donc le disque semblait « sain » si vous ne regardiez que les mauvais compteurs.

Ils ont remplacé un seul câble dans le châssis lors d’une fenêtre de maintenance. Les blocages ont cessé. Pas de debugging héroïque à minuit. Pas de remplacement de la moitié du serveur « au cas où ». Juste une habitude disciplinée : conserver les logs, comparer les incidents, suivre les preuves.

Cette pratique semble ennuyeuse jusqu’à ce qu’elle vous sauve la semaine. Ensuite, elle ressemble à du professionnalisme.

Erreurs courantes : symptôme → cause racine → correctif

Cette section est volontairement précise. Si vous vous y reconnaissez, tant mieux. Les correctifs coûtent moins cher que l’orgueil.

1) « Ça ne se fige que quand je joue » → hypothèse GPU → réalité stockage/PCIe

Symptôme : Blocage dur en charge, pas de BSOD, son qui boucle.
Cause probable : Timeouts NVMe lors d’écritures de cache shader, streaming d’actifs de jeu, ou activité de pagefile ; ou problèmes de lien PCIe se manifestant par des erreurs AER corrigées.
Correctif : Vérifiez les journaux pour réinitialisations/timeouts NVMe ; mettez à jour BIOS et firmware SSD ; testez la désactivation d’ASPM/APST ; assurez‑vous que les pilotes chipset sont à jour ; validez le refroidissement du SSD.

2) « Aucun signal dans SMART, le disque est sain » → ignorer les mauvais compteurs

Symptôme : Le système se bloque puis récupère ; les blocages s’aggravent ensuite.
Cause probable : Erreurs CRC (câble/backplane), entrées dans le journal d’erreur NVMe, ou stalls au niveau firmware non reflétés par le statut SMART « PASSED ».
Correctif : Vérifiez UDMA_CRC_Error_Count (SATA) et les journaux d’erreurs NVMe ; remplacez les câbles ; reseatez les périphériques ; validez les erreurs PCIe.

3) « Activer le cache d’écriture l’a rendu plus rapide » → latence tail et risque perte d’alim

Symptôme : Meilleurs résultats aux benchmarks, pires blocages réels, surtout lors d’écritures lourdes.
Cause probable : Politiques de cache interagissant avec la garbage collection du firmware ou le comportement des flush ; l’augmentation de la mise en file masque les problèmes jusqu’à ce que ça ne marche plus.
Correctif : Utilisez des tests axés latence (fio avec percentiles clat) ; gardez les réglages de cache conservateurs sauf si vous avez une protection d’alimentation et une validation.

4) « C’est le système de fichiers » → traiter la corruption comme cause au lieu de conséquence

Symptôme : Avertissements du système de fichiers après redémarrage forcé.
Cause probable : Échecs I/O sous‑jacents entraînant des écritures incomplètes.
Correctif : Stabilisez d’abord le chemin de stockage ; puis lancez la réparation du système de fichiers ; restaurez depuis des sauvegardes si des erreurs permanentes existent.

5) « Augmentons la concurrence pour finir plus vite » → saturation du périphérique jusqu’à la défaillance

Symptôme : La fréquence des blocages augmente quand vous « accélérez » la charge.
Cause probable : Profondeur de file et écritures soutenues déclenchant le pire comportement firmware ou la limitation thermique conduisant à des timeouts.
Correctif : Limitez la concurrence/iodepth ; améliorez le refroidissement ; validez avec iostat et fio ; envisagez des SSD plus haut de gamme conçus pour des écritures soutenues.

6) « Pas de logs parce que ça a gelé » → ne pas conserver les logs du boot précédent

Symptôme : Rien d’utile après redémarrage ; tout le monde improvise.
Cause probable : Logs tournés, journal volatile, pas de persistance des crashs.
Correctif : Activez journald persistant, augmentez la rétention, exportez les logs. Si vous ne pouvez pas voir le boot précédent, vous ne pouvez pas faire de forensique.

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

Utilisez ceci comme plan opérationnel. Imprimez‑le. Exécutez‑le comme un incident, pas comme un passe‑temps.

Checklist A: First 30 minutes after a freeze

Notez l’heure approximative du blocage et ce que faisait le système (copie de fichiers, mise à jour, jeu, compilation, sauvegarde VM).
Après le redémarrage, récupérez immédiatement les logs du boot précédent :
- Linux : journalctl -k -b -1
- Windows : journal System autour du moment du blocage et au démarrage suivant
Cherchez : timeouts, réinitialisations, erreurs I/O, événements AER/WHEA.
Capturez le contexte matériel : modèle SSD, firmware, version BIOS, versions des pilotes de stockage.
Si des erreurs de stockage existent : sauvegardez maintenant. Ne « attendez pas un autre blocage ».

Checklist B: Controlled reproduction and isolation

Exécutez une charge I/O contrôlée (fio ou équivalent) et surveillez :
- iostat -x 1 pour await/utilization
- les journaux kernel pour réinitialisations/timeouts
Testez une variable à la fois :
- Désactivez ASPM (dépend de la plateforme) et retestez
- Désactivez/réduisez NVMe APST (paramètre noyau Linux) et retestez
- Mettez à jour le firmware SSD et retestez
- Mettez à jour le BIOS/UEFI et retestez
Si SATA : échangez le câble/port backplane ; retestez.
Si reproductible uniquement à chaud : mesurez les températures SSD ; améliorez le refroidissement ; retestez.

Checklist C: If you cannot reproduce, but freezes continue

Augmentez l’observabilité :
- Activez la persistance des journaux (stockage persistant journald)
- Activez la configuration de dump core/kernel (le cas échéant)
Recherchez des signaux progressifs :
- Augmentation des entrées du journal d’erreurs NVMe
- Augmentation des compteurs d’erreurs CRC
- Augmentation des erreurs PCIe corrigées
Planifiez une fenêtre de maintenance pour reseater le matériel et mettre à jour les firmwares.
Fixez un seuil de remplacement : si des réinitialisations surviennent plus d’une fois par semaine, cessez de débattre et remplacez le périphérique/chemin.

FAQ

1) Pourquoi pas de BSOD ? Windows/Linux ne devraient‑ils pas planter si le stockage meurt ?

Non. Les deux OS tentent de récupérer des incidents de stockage par des reprises et des réinitialisations. Un blocage peut être l’OS attendant une I/O, pas une exception fatale.

2) Je vois Event ID 129 sous Windows. Mon SSD est‑il mort ?

Ça signifie que Windows a réinitialisé le périphérique de stockage parce qu’il a cessé de répondre. Le SSD peut être défectueux, mais cela peut aussi être le firmware, la gestion d’alimentation PCIe, un slot instable, ou un problème de pilote. Traitez‑le comme une instabilité du chemin de stockage.

3) Linux affiche « controller is down; will reset ». Est‑ce toujours matériel ?

Souvent, mais pas toujours. Cela peut être un bug de firmware déclenché par APST/ASPM, une limitation thermique, ou un problème de lien PCIe. Le remplacement matériel est parfois la solution la plus rapide, mais validez d’abord avec des tests de firmware et d’états d’alimentation.

4) Un mauvais câble SATA peut‑il vraiment geler un système ?

Oui. Les erreurs CRC entraînent des reprises ; les reprises entraînent des stalls ; les stalls font paraître l’OS gelé — surtout si ce disque est occupé ou héberge le journal/OS.

5) Mon statut SMART indique « PASSED ». Pourquoi suspecter encore le stockage ?

Parce que « PASSED » n’est pas une garantie. Regardez des compteurs spécifiques (secteurs pending, erreurs CRC, journaux d’erreurs NVMe) et les journaux timeout du noyau/OS. Ceux‑ci reflètent mieux la réalité.

6) Cela pourrait‑il être de l’instabilité RAM ou CPU ?

Absolument. Si vous voyez des soft lockups watchdog sans erreurs de stockage, ou des erreurs réparties sur des sous‑systèmes non liés, lancez des tests mémoire et retirez overclocks/undervolts. Mais ne négligez pas les journaux de stockage — ils montrent souvent la première rupture visible.

7) Si désactiver ASPM/APST règle le problème, est‑ce la « solution finale » ?

Ça peut être un contournement de production acceptable, surtout sur postes. La « solution finale » est généralement une mise à jour BIOS/firmware SSD ou un remplacement matériel permettant une gestion d’alimentation sûre sans blocages.

8) Comment éviter de perdre les preuves après une coupure de courant ?

Sous Linux, assurez‑vous que journald est persistant et que les logs ne restent pas seulement en mémoire. Sous Windows, assurez‑vous que les journaux d’événements sont conservés assez longtemps et ne sont pas écrasés. Notez aussi les heures de blocage pour pouvoir corréler.

9) Et si le blocage survient avant que l’OS n’ait le temps de journaliser ?

Alors vous vous appuyez sur ce qui survit : journaux firmware (si disponibles), indicateurs matériels, et preuves cross‑boot (journaux du boot précédent, compteurs SMART/NVMe qui s’incrémentent). Vous tentez aussi de reproduire sous charge contrôlée et de changer une variable à la fois.

10) Les disques externes USB causent‑ils aussi des blocages ?

Oui, en particulier les périphériques bus‑powered ou les boîtiers défectueux. Les timeouts de stockage USB peuvent bloquer l’I/O et provoquer des stalls système, selon ce qui est monté et comment l’OS le gère.

Prochaines étapes réalisables aujourd’hui

Cessez de traiter « sans BSOD » comme « pas d’indice ». L’indice se trouve généralement dans vos journaux de timeouts de stockage, documentant silencieusement chaque fois que votre système a dû réinitialiser un périphérique pour continuer.

Faites ceci :

Récupérez les journaux du boot précédent (kernel/system) et cherchez timeouts/réinitialisations (NVMe/SATA/AER/WHEA).
Si vous les trouvez, sauvegardez immédiatement et commencez par des mises à jour firmware/BIOS et des tests de gestion d’alimentation (ASPM/APST).
Mesurez la latence tail sous charge. Si votre latence max atteint des secondes, c’est votre générateur de blocage.
Si les preuves pointent vers un disque ou un chemin spécifique, remplacez‑le. Ce n’est pas un échec moral ; c’est de la maintenance.

L’objectif n’est pas de gagner une dispute avec la machine. L’objectif est de rendre les blocages ennuyeusement impossibles. Les journaux vous y mèneront — si vous lisez les bons.