Prendre rendez-vous
  1. Accueil
  2. /
  3. Blog
  4. /
  5. Diagnostiquer pannes hardware : memtest86, stress-ng, badblocks et analyse logs kernel

Administration
Infrastructure
Monitoring

Diagnostiquer pannes hardware : memtest86, stress-ng, badblocks et analyse logs kernel

16 janvier 2026

13 min de lecture

Sommaire
Plan
Symptômes de pannes hardware
Tests RAM : memtest86+ et stress-ng
Tests CPU : stress-ng et torture
Tests disques : badblocks et SMART
Analyse logs kernel : dmesg, MCE, EDAC
Tests PSU et surchauffe
Procédures de diagnostic méthodiques
Checklist diagnostic hardware
Scripts automatiques
Conclusion

Les pannes hardware sont difficiles à diagnostiquer car les symptômes sont variés. Ce guide détaille les outils essentiels pour tester RAM, CPU, disques et identifier les défaillances matérielles via les logs kernel.

Plan

  • Symptômes de pannes hardware
  • Tests RAM : memtest86+ et stress-ng
  • Tests CPU : stress-ng et torture
  • Tests disques : badblocks et SMART
  • Analyse logs kernel : dmesg, MCE, EDAC
  • Tests PSU et surchauffe
  • Procédures de diagnostic méthodiques (voir monitoring matériel)
  • Conclusion

Symptômes de pannes hardware

Pannes RAM

Symptômes :

  • Kernel panics aléatoires
  • Segmentation faults fréquents
  • Applications crash sans raison
  • Corruption de données
  • Freeze système aléatoire

Logs typiques :

kernel: MCE: CPU 0: Machine Check Exception
kernel: Memory failure at address 0x7f8b4c000000
kernel: segfault at 7fff12345678 ip 00007f9abc123456
Pannes CPU

Symptômes :

  • Calculs incorrects
  • Crash sous charge élevée
  • Throttling thermique constant
  • Kernel panics pendant stress tests
  • Instabilité overclocking

Logs typiques :

kernel: CPU0: Package temperature above threshold
kernel: CPU0: Core temperature above threshold
kernel: mce: [Hardware Error]: Machine check events logged
Pannes disques

Symptômes :

  • I/O errors fréquents
  • Lenteur soudaine
  • Fichiers corrompus
  • Bad sectors
  • Clics mécaniques (HDD)

Logs typiques :

kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
kernel: ata1.00: BMDMA stat 0x24
kernel: sd 0:0:0:0: [sda] Sense Key : Medium Error [current]
kernel: end_request: I/O error, dev sda, sector 1234567
Pannes PSU/alimentation

Symptômes :

  • Reboots spontanés
  • Freeze sous charge élevée
  • Sous-voltage détecté
  • Composants s'éteignent aléatoirement

Logs typiques :

kernel: ACPI: Battery voltage too low
kernel: Power supply unit failure detected

Tests RAM : memtest86+ et stress-ng

memtest86+ (test exhaustif)
# Installer
apt install memtest86+

# Mettre à jour GRUB
update-grub

# Reboot et sélectionner memtest86+ au boot
reboot

Test memtest86+ :

  • Laisser tourner minimum 8 heures
  • 1 pass complet = ~2-4h selon RAM
  • Objectif : 3+ passes sans erreur
  • 1 seule erreur = RAM défectueuse

Interpréter résultats :

Pass: 1
Test: 1/11 (Address test, walking ones, no cache)
Errors: 0

Pass: 1
Test: 2/11 (Address test, own address)
Errors: 3  ← RAM DÉFECTUEUSE

Test 2: Barrette slot 2, adresses 0x7f8b4c000000-0x7f8b4c003fff
Action: Retirer barrette slot 2, relancer test
stress-ng (test RAM en production)
# Installer
apt install stress-ng

# Test RAM uniquement (4GB, 60s)
stress-ng --vm 4 --vm-bytes 1G --timeout 60s --metrics-brief

# Test intensif (80% RAM, 300s)
TOTAL_RAM=$(free -g | awk '/^Mem:/{print $2}')
TEST_RAM=$((TOTAL_RAM * 80 / 100))
stress-ng --vm 8 --vm-bytes ${TEST_RAM}G --timeout 300s --verify

Options importantes :

  • --vm : nombre de workers
  • --vm-bytes : mémoire par worker
  • --verify : vérifier intégrité données
  • --vm-method : all/flip/inc/rand/…
# Test exhaustif avec vérification
stress-ng --vm 4 --vm-bytes 2G --vm-method all --verify --timeout 600s

# Si erreurs détectées
stress-ng: error: [12345] vm instance 2: memory corruption detected
# → RAM défectueuse
Identifier barrette défectueuse
# Voir layout RAM
dmidecode --type 17

# Exemple sortie :
# Handle 0x0011, DMI type 17, 40 bytes
# Memory Device
#   Total Width: 64 bits
#   Size: 16 GB
#   Locator: DIMM_A1
#   Bank Locator: BANK 0

# Test par barrette (retirer toutes sauf 1, tester)
# 1. Retirer toutes barrettes sauf slot 1
# 2. memtest86+ 8h
# 3. Si OK, tester slot 2
# 4. Répéter jusqu'à trouver barrette défectueuse

Tests CPU : stress-ng et torture

stress-ng (stress multi-composants)
# Test CPU tous les cores (60s)
stress-ng --cpu $(nproc) --timeout 60s --metrics-brief

# Test intensif avec température monitoring
stress-ng --cpu $(nproc) --timeout 300s --metrics-brief &
watch -n 1 sensors

Si crash pendant stress CPU → CPU défectueux ou refroidissement

mprime / Prime95 (torture test)
# Télécharger mprime (version Linux de Prime95)
wget https://www.mersenne.org/ftp_root/gimps/p95v3019b20.linux64.tar.gz
tar xzf p95v3019b20.linux64.tar.gz
cd mprime

# Lancer torture test
./mprime -t

# Options :
# 1. Small FFTs (stress CPU, chauffe max)
# 2. In-place large FFTs (stress CPU + RAM)
# 3. Blend (stress CPU + RAM + cache)

# Laisser tourner 24h minimum
# 0 erreur = stable
# Erreurs = CPU instable ou RAM défectueuse
Tests spécifiques

Test AVX2/AVX-512 (instructions modernes) :

# stress-ng avec AVX
stress-ng --cpu $(nproc) --cpu-method ackermann --timeout 300s

# Si CPU crash avec AVX mais pas sans
# → Instabilité AVX (souvent overclocking trop agressif)

Test multi-threaded :

# Compiler stress test custom
cat > cpu_test.c << 'EOF'
#include <stdio.h>
#include <math.h>
#include <pthread.h>

void* worker(void* arg) {
    long id = (long)arg;
    double result = 0.0;
    for (long i = 0; i < 1000000000; i++) {
        result += sqrt(i) * sin(i);
    }
    printf("Thread %ld done: %f\n", id, result);
    return NULL;
}

int main() {
    pthread_t threads[32];
    for (long i = 0; i < 32; i++) {
        pthread_create(&threads[i], NULL, worker, (void*)i);
    }
    for (int i = 0; i < 32; i++) {
        pthread_join(threads[i], NULL);
    }
    return 0;
}
EOF

gcc -o cpu_test cpu_test.c -lm -lpthread
./cpu_test

Tests disques : badblocks et SMART

badblocks (test exhaustif)
# Test lecture seule (non destructif)
badblocks -sv /dev/sda

# Test écriture (DESTRUCTIF, efface données)
badblocks -wsv /dev/sda

# Test avec pattern spécifique
badblocks -wsv -t 0xaa /dev/sda
badblocks -wsv -t 0x55 /dev/sda

# Logs
# Testing with pattern 0xaa: done
# Testing with pattern 0x55: done
# Testing with pattern 0xff: done
# Testing with pattern 0x00: done
# Pass completed, 0 bad blocks found.

Si bad blocks détectés :

# Marquer bad blocks dans filesystem
badblocks -sv /dev/sda > /tmp/badblocks.txt
e2fsck -l /tmp/badblocks.txt /dev/sda1

# Mais ATTENTION : >5 bad blocks = remplacer disque immédiatement
SMART extended test
# Test court (2 min)
smartctl -t short /dev/sda

# Test long (2-4h selon taille)
smartctl -t long /dev/sda

# Voir progression
smartctl -a /dev/sda | grep "Self-test execution status"

# Résultats
smartctl -l selftest /dev/sda
# Num  Test_Description    Status                  Remaining  LifeTime(hours)
# 1    Extended offline    Completed without error       00%      1234

Attributs SMART critiques :

smartctl -A /dev/sda | grep -E "Reallocated|Pending|Uncorrectable|UDMA_CRC"

# 5   Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always  -  0
# 197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always  -  0
# 198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline -  0

# Si valeur RAW > 0 : disque en fin de vie, remplacer
Test performance disque
# Test lecture séquentielle
hdparm -t /dev/sda
# Timing buffered disk reads: 350 MB in  3.01 seconds = 116.28 MB/sec

# Si < 50 MB/s sur HDD SATA : disque défaillant
# Si < 300 MB/s sur SSD SATA : problème

# Test avec dd
dd if=/dev/sda of=/dev/null bs=1M count=1000 status=progress
# 1048576000 bytes (1.0 GB, 1000 MiB) copied, 8.5 s, 123 MB/s

Analyse logs kernel : dmesg, MCE, EDAC

dmesg (kernel ring buffer)
# Voir tous les logs kernel
dmesg | less

# Filtrer erreurs hardware
dmesg | grep -i "error\|fail\|hardware\|mce\|edac"

# Filtrer par composant
dmesg | grep -i "memory"
dmesg | grep -i "cpu"
dmesg | grep -i "ata\|sd"
dmesg | grep -i "pci"

# Logs temps réel
dmesg -w

Exemples erreurs critiques :

# Erreur RAM
kernel: EDAC MC0: CE page 0x7f8b4c, offset 0x1000, grain 4096, syndrome 0x0086
kernel: EDAC MC0: CE - no information available: DIMM Label: "DIMM_A1"

# Erreur CPU
kernel: mce: [Hardware Error]: Machine check events logged
kernel: mce: [Hardware Error]: CPU 0: Machine Check: 4 Bank 5: be00000000000108

# Erreur disque
kernel: ata1.00: exception Emask 0x0 SAct 0x7 SErr 0x0 action 0x0
kernel: ata1.00: failed command: READ FPDMA QUEUED

# Erreur PCIe
kernel: pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer
MCE (Machine Check Exception)
# Installer mcelog
apt install mcelog

# Voir erreurs MCE
mcelog --client

# Exemple sortie :
# Hardware event. This is not a software error.
# MCE 0
# CPU 0 BANK 5
# MISC 86000000000086 ADDR 7f8b4c001000
# TIME 1642345678 Wed Jan 16 12:34:38 2026
# MCG status:
# MCi status: Corrected error
# MCi_MISC register valid
# MCi_ADDR register valid
# Memory read error
# Transaction: Memory
# MemCtrl ID = 0, Channel = 1, DIMM = 0

# Logs continus
mcelog --daemon
journalctl -u mcelog -f

Interpréter MCE :

  • Corrected error : erreur corrigée par ECC, surveiller
  • Uncorrected error : erreur non corrigée, critique
  • Memory read error : problème RAM
  • CPU/Cache error : problème CPU
EDAC (Error Detection And Correction)
# Charger modules EDAC
modprobe edac_core
modprobe edac_mce_amd  # AMD
modprobe ie31200_edac  # Intel

# Voir erreurs détectées
cat /sys/devices/system/edac/mc/mc*/ce_count
# 0 = OK, >0 = erreurs corrigées détectées

# Détails par DIMM
grep . /sys/devices/system/edac/mc/mc*/csrow*/ch*_ce_count
# mc0/csrow0/ch0_ce_count:0
# mc0/csrow0/ch1_ce_count:5  ← 5 erreurs corrigées sur channel 1

# Logs EDAC
dmesg | grep EDAC
journalctl (logs système)
# Logs hardware depuis boot
journalctl -b | grep -i "hardware\|error\|fail"

# Logs kernel uniquement
journalctl -k

# Logs par priorité (error et plus grave)
journalctl -p err

# Logs temps réel
journalctl -f

Tests PSU et surchauffe

Test charge PSU
# Stress complet système (CPU + RAM + I/O)
stress-ng --cpu $(nproc) --vm 4 --vm-bytes 2G --io 4 --hdd 2 --timeout 600s --metrics-brief

# Monitorer pendant test
watch -n 1 'sensors; uptime; free -h'

Si reboot pendant stress → PSU insuffisant ou défectueux

Monitoring températures
# Installer lm-sensors
apt install lm-sensors
sensors-detect

# Températures en continu
watch -n 1 sensors

# Script alerte température
cat > /tmp/temp_monitor.sh << 'EOF'
#!/bin/bash
while true; do
    CPU_TEMP=$(sensors | grep "Package id 0" | awk '{print $4}' | sed 's/+//;s/°C//')
    if (( $(echo "$CPU_TEMP > 85" | bc -l) )); then
        echo "CRITICAL: CPU temp ${CPU_TEMP}°C"
        stress-ng --cpu 0 --timeout 1s  # Kill stress test
    fi
    sleep 1
done
EOF

bash /tmp/temp_monitor.sh &
Test ventilateurs
# Voir vitesse ventilateurs
sensors | grep fan

# Si 0 RPM ou < 500 RPM : ventilateur défectueux

# Test manuel ventilateur (si controllable)
echo 255 > /sys/class/hwmon/hwmon0/pwm1  # Max speed
sleep 5
sensors | grep fan
# Fan devrait être à max RPM

echo 128 > /sys/class/hwmon/hwmon0/pwm1  # 50% speed

Procédures de diagnostic méthodiques

Procédure panne aléatoire
# 1. Vérifier logs kernel
dmesg | tail -100
journalctl -p err -n 100

# 2. Test RAM (8h)
reboot # sélectionner memtest86+

# 3. Si RAM OK, test CPU
stress-ng --cpu $(nproc) --timeout 3600s

# 4. Si CPU OK, test disques
for disk in /dev/sd[a-z]; do
    smartctl -H $disk
    smartctl -l selftest $disk
done

# 5. Si tout OK, vérifier PSU et température
stress-ng --cpu $(nproc) --vm 4 --io 4 --timeout 600s
watch sensors
Procédure corruption données
# 1. Test RAM PRIORITAIRE
stress-ng --vm 4 --vm-bytes 2G --vm-method all --verify --timeout 3600s

# 2. Si erreurs mémoire
stress-ng: error: memory corruption detected
# → Test memtest86+ 8h minimum
# → Identifier barrette défectueuse

# 3. Test disque
smartctl -t long /dev/sda
# Attendre fin puis :
smartctl -l selftest /dev/sda

# 4. Test filesystem
umount /dev/sda1
e2fsck -fv /dev/sda1  # ext4
xfs_repair -v /dev/sda1  # xfs
Procédure crash sous charge
# 1. Monitoring température pendant crash
sensors > /tmp/temps_before.txt
stress-ng --cpu $(nproc) --timeout 60s &
watch -n 1 "sensors | tee -a /tmp/temps_during.txt"

# 2. Si throttling ou >85°C
# → Problème refroidissement
# → Nettoyer radiateur, changer pâte thermique

# 3. Si température OK
# → Test PSU
stress-ng --cpu $(nproc) --vm 4 --io 4 --hdd 2 --timeout 600s

# 4. Si reboot pendant stress
# → PSU insuffisant ou défectueux
# → Vérifier wattage PSU vs consommation

Checklist diagnostic hardware

✅ Tests RAM :

  • memtest86+ 8h minimum
  • stress-ng avec --verify
  • MCE/EDAC logs vérifiés
  • Barrettes testées individuellement si erreur

✅ Tests CPU :

  • stress-ng CPU 1h
  • mprime torture 24h
  • Températures surveillées
  • MCE errors vérifiés

✅ Tests disques :

  • SMART health OK
  • SMART extended test
  • badblocks lecture
  • Performance test (hdparm/dd)
  • dmesg I/O errors vérifiés

✅ Tests système :

  • PSU stress test complet
  • Ventilateurs vérifiés (RPM)
  • Températures sous charge
  • Logs kernel analysés

✅ Documentation :

  • Résultats tests documentés
  • Erreurs logs sauvegardées
  • Composants défectueux identifiés
  • Procédure remplacement planifiée

Scripts automatiques

Script diagnostic complet
#!/bin/bash
# /usr/local/bin/hardware-diag.sh

LOG_DIR="/var/log/hardware-diag"
mkdir -p $LOG_DIR
DATE=$(date +%Y%m%d_%H%M%S)

echo "=== Hardware Diagnostic Started: $DATE ===" | tee $LOG_DIR/diag_${DATE}.log

# 1. System info
echo -e "\n=== System Info ===" | tee -a $LOG_DIR/diag_${DATE}.log
lscpu | tee -a $LOG_DIR/diag_${DATE}.log
free -h | tee -a $LOG_DIR/diag_${DATE}.log
lsblk | tee -a $LOG_DIR/diag_${DATE}.log

# 2. Kernel errors
echo -e "\n=== Kernel Errors ===" | tee -a $LOG_DIR/diag_${DATE}.log
dmesg | grep -i "error\|fail\|hardware" | tail -50 | tee -a $LOG_DIR/diag_${DATE}.log

# 3. MCE errors
if command -v mcelog &> /dev/null; then
    echo -e "\n=== MCE Errors ===" | tee -a $LOG_DIR/diag_${DATE}.log
    mcelog --client | tee -a $LOG_DIR/diag_${DATE}.log
fi

# 4. SMART status
echo -e "\n=== SMART Status ===" | tee -a $LOG_DIR/diag_${DATE}.log
for disk in /dev/sd[a-z] /dev/nvme[0-9]n[0-9]; do
    if [ -e "$disk" ]; then
        echo "--- $disk ---" | tee -a $LOG_DIR/diag_${DATE}.log
        smartctl -H $disk | tee -a $LOG_DIR/diag_${DATE}.log
        smartctl -A $disk | grep -E "Reallocated|Pending|Uncorrectable" | tee -a $LOG_DIR/diag_${DATE}.log
    fi
done

# 5. Memory test (quick)
echo -e "\n=== Memory Quick Test ===" | tee -a $LOG_DIR/diag_${DATE}.log
stress-ng --vm 2 --vm-bytes 1G --verify --timeout 60s 2>&1 | tee -a $LOG_DIR/diag_${DATE}.log

# 6. CPU test (quick)
echo -e "\n=== CPU Quick Test ===" | tee -a $LOG_DIR/diag_${DATE}.log
stress-ng --cpu $(nproc) --timeout 60s --metrics-brief 2>&1 | tee -a $LOG_DIR/diag_${DATE}.log

# 7. Temperatures
echo -e "\n=== Temperatures ===" | tee -a $LOG_DIR/diag_${DATE}.log
sensors | tee -a $LOG_DIR/diag_${DATE}.log

echo -e "\n=== Diagnostic Complete ===" | tee -a $LOG_DIR/diag_${DATE}.log
echo "Log saved to: $LOG_DIR/diag_${DATE}.log"
# Rendre exécutable
chmod +x /usr/local/bin/hardware-diag.sh

# Lancer
/usr/local/bin/hardware-diag.sh

Conclusion

Le diagnostic hardware nécessite une approche méthodique et des tests exhaustifs. Les outils memtest86+, stress-ng, badblocks et l'analyse des logs kernel permettent d'identifier précisément les composants défectueux.

Points clés :

  • RAM : memtest86+ 8h minimum
  • CPU : stress-ng + mprime 24h
  • Disques : SMART tests + badblocks
  • Logs kernel : dmesg, MCE, EDAC essentiels
  • Tests charge complète pour PSU

Symptômes vs composants :

  • Crash aléatoire → RAM
  • Crash sous charge → PSU/refroidissement
  • Corruption données → RAM/disque
  • Calculs incorrects → CPU
  • I/O errors → disque

Actions prioritaires :

  1. Sauvegarder logs kernel avant tests
  2. Commencer par RAM (cause #1)
  3. Tests exhaustifs (8h+ RAM, 24h+ CPU)
  4. Remplacer proactivement composants douteux
  5. Documenter tous les tests
Besoin d'aide sur ce sujet ?

Notre équipe d'experts est là pour vous accompagner dans vos projets d'infrastructure et d'infogérance.

Contactez-nous

Articles similaires

VictoriaMetrics : la TSDB qui allège votre stack monitoring
Monitoring
Performance
Infrastructure

VictoriaMetrics : la TSDB qui allège votre stack monitoring

VictoriaMetrics est une base de séries temporelles compatible PromQL, taillée pour absorber des millions de séries actives avec une empreinte mémoire et disque très inférieure à Prometheus. Architecture, composants, cas d'usage.

7 mai 2026

Lire plus

Zabbix 7 : déployer un monitoring d'infrastructure complet en 2026
Monitoring
Infrastructure

Zabbix 7 : déployer un monitoring d'infrastructure complet en 2026

Guide complet pour installer et configurer Zabbix 7 LTS. Templates, alertes, découverte automatique et comparaison avec Prometheus/Grafana.

16 mars 2026

Lire plus

Proxmox Datacenter Manager : centraliser la gestion multi-noeuds en production
Infrastructure
Administration

Proxmox Datacenter Manager : centraliser la gestion multi-noeuds en production

Retour terrain sur PDM 1.0, l'outil de gestion centralisée multi-clusters Proxmox. Architecture Rust, migration inter-clusters, limites et cas d'usage MSP.

10 mars 2026

Lire plus


SHPV, votre partenaire de confiance en infrastructure et infogérance informatique en France.

SHPV
Prendre rendez-vousNous contacter
Expertise
InfrastructureDatacenterInfogéranceCloudHébergementTransit IP
Légales
Conditions Générales de VenteCPS - Contrat de ServicesCPS - Hébergement CloudCPS - Microsoft 365Accord sous-traitance RGPDTarifs interventions

SHPV © 2026 - Tous droits réservés

Mentions légalesPolitiques de confidentialité
SHPV FRANCE - SAS au capital de 16 000 € - 52 Rue Romain Rolland, 71230 Saint-Vallier - SIRET n°80886287400035 - R.C.S. Chalon-sur-Saône. Par téléphone 09 72 310 818 - Email: support@shpv.fr