CPU matériel : le piège de la mise à niveau — BIOS, microcode et VRM, remise à plat

Le vrai contrat de mise à niveau : le socket n’est pas la compatibilité

Les gens adorent le tableau des sockets. « C’est LGAxxxx, donc on est bons. » Ou « AM4 prend en charge cette génération. » C’est de la compatibilité marketing. La compatibilité au niveau production est plus problématique :

• Le BIOS/UEFI doit reconnaître le CPU (CPUID, stepping, séquence d’initialisation, règles de training mémoire).
• Le microcode doit être acceptable (atténuations de sécurité, contournements d’errata, correctifs de stabilité).
• Les VRM et l’alimentation de la carte doivent survivre à la réalité (courant soutenu, réponse transitoire, conception thermique).
• Les limites de puissance de la plateforme doivent correspondre à votre charge (PL1/PL2/Tau, EDC/TDC/PPT, cTDP, réglages « auto »).
• Le refroidissement doit correspondre au comportement de boost (le turbo est autant une politique thermique qu’une politique d’horloge).
• L’OS et l’hyperviseur doivent ordonnancer correctement (nouvelle topologie, cœurs hybrides, CPPC, comportement du SMT).

Quand l’un de ces éléments est « presque correct », vous n’obtenez pas une panne nette. Vous obtenez des fautes intermittentes, des chutes de performance et des spams mystérieux « hardware corrected error » que tout le monde ignore jusqu’à ce qu’ils ne soient plus corrigés.

Vérité sèche : en environnement entreprise, la carte mère est le produit et le CPU est une option prise en charge. En environnement hobby, le CPU est le produit et la carte est une suggestion. N’amenez pas des hypothèses de hobby dans une fenêtre de changement.

BIOS vs microcode vs VRM : qui fait réellement tourner votre CPU ?

BIOS/UEFI : le videur à l’entrée du club

Le BIOS/UEFI est la première couche de vérité. Il initialise le CPU, définit les politiques de puissance, entraîne la mémoire et expose des réglages (parfois factices) à l’OS. Si le BIOS n’inclut pas le bon code d’init du CPU, vous pouvez ne pas démarrer, ou démarrer avec un comportement dégradé : bins turbo limités, fonctions désactivées ou training mémoire instable.

Les BIOS modernes livrent aussi du microcode intégré. C’est important parce que le microcode est effectivement une couche de correctifs pour le comportement du CPU. Le CPU sort d’usine avec un microcode, mais il peut être remplacé tôt au démarrage, soit par le firmware soit par l’OS.

Microcode : le correctif discret que vous n’avez pas testé

Les mises à jour de microcode corrigent des errata, des problèmes de stabilité et appliquent des atténuations de sécurité. Elles peuvent aussi modifier les caractéristiques de performance de façon non évidente : comportement de spéculation, fencing, ou l’agressivité du boost dans certaines conditions.

Vous n’« installez » pas le microcode comme un pilote. Vous le déployez comme vous déployez un nouveau noyau : contrôlé, surveillé, avec rollback. Si vous n’avez jamais vu une mise à jour de microcode déclencher une boucle de redémarrage sur un stepping spécifique, félicitations pour votre jeunesse.

Une citation que les opérations ont tendance à intégrer après suffisamment d’incidents :

« L’espoir n’est pas une stratégie. » — Gen. Gordon R. Sullivan

VRM : la pièce à laquelle vous n’avez pas prêté attention parce que ce n’est pas brillant

Le CPU est alimenté par des modules régulateurs de tension (VRM). Les VRM convertissent le 12V (ou d’autres rails) en une tension stable pour les cœurs CPU à des courants très élevés. Le comportement de boost du CPU est un sport de courant transitoire : la puce demandera de grosses rafales d’énergie pendant de courtes périodes, et le VRM doit répondre sans chute, surtension ou surchauffe.

Le marketing des cartes mères parle de « phases ». Les ingénieurs se préoccupent de la capacité de courant effective, de la réponse transitoire et des thermiques. Une carte peut afficher beaucoup de phases et mal se comporter si la conception est bon marché ou mal refroidie. En serveurs, les VRM sont conçus autour de SKUs CPU spécifiques et validés avec eux. Sur des cartes grand public, le fossé entre « prend en charge » et « aime fonctionner » est là où résident vos pannes.

Blague #1 : Une mise à niveau CPU, c’est comme adopter un chien plus gros. La laisse (VRM) est ce qui casse en premier, pas le chien.

Courte histoire et faits qui expliquent le bazar actuel

Ce ne sont pas des trivia pour le plaisir. Ils expliquent pourquoi « il suffit d’échanger le CPU » tourne sans cesse en post-mortem.

1. Les mises à jour de microcode existent depuis des décennies, mais le microcode distribué par l’OS est devenu courant dans les années 2000 à mesure que les plateformes se complexifiaient et que les atténuations de sécurité comptaient.
2. Les atténuations de l’exécution spéculative après Spectre/Meltdown ont modifié les performances pour certaines charges, surtout celles riches en appels système et en changements de contexte.
3. Les limites de puissance turbo d’Intel (PL1/PL2/Tau) ont transformé le « TDP » en un choix de politique ; les cartes ont commencé à expédier des réglages « illimités » parce que les benchs vendent des cartes mères.
4. Le comportement de boost et CPPC d’AMD dépend de plus en plus de la coordination firmware + OS ; une mise à jour du BIOS peut changer le boost plus qu’un échange de CPU.
5. La complexité du training mémoire a explosé avec des fréquences DDR plus élevées ; les versions de BIOS diffèrent énormément en stabilité de training, surtout avec des DIMMs mixtes ou une intégrité de signal borderline.
6. Les fournisseurs de serveurs valident des steppings CPU spécifiques ; deux puces portant le même nom SKU peuvent se comporter différemment si stepping et microcode divergent.
7. Les limites thermiques des VRM dépendent de la charge ; une carte peut passer un benchmark court et quand même brider ou planter sous des charges AVX soutenues ou de compression.
8. Le comportement de fréquence AVX (dowclocking sous charges vectorielles larges) est souvent mal compris ; « CPU plus rapide » peut être plus lent si votre charge déclenche des fréquences soutenues plus basses.

Modes de panne que vous verrez en production

1) Démarre bien, puis redémarre sous charge

Classique protection transitoire ou thermique des VRM, ou politique de puissance « auto » trop agressive. Vous le verrez dans la compression, le chiffrement, l’analytics lourd en AVX ou les serveurs de build en parallèle.

2) Le CPU « mis à niveau » est plus lent que l’ancien

Coupables fréquents :

• Un nouveau microcode active des atténuations qui impactent plus que prévu votre charge.
• Les limites de puissance sont conservatrices (PL1 épinglé au TDP avec un Tau court).
• La gestion thermique commence plus tôt parce que le nouveau CPU booste différemment.
• Des changements NUMA/topologie provoquent une inefficacité du planificateur (surtout dans les VM).

3) Erreurs corrigées aléatoires (WHEA/EDAC) qui « ne sont pas un problème » jusqu’à ce qu’elles le soient

Les erreurs machine check corrigées peuvent indiquer une stabilité marginale : problèmes de training mémoire, Vcore borderline, chute de VRM ou problèmes de signalisation PCIe après un changement de plateforme. La production adore transformer « corrigé » en « non corrigé » pendant le pic de trafic.

4) Ne POSTe pas, ou POSTe seulement après reset du BIOS

Cela provient souvent d’un support CPU manquant dans le BIOS, ou d’une régression de training mémoire. Autre cas : des cartes qui requièrent un BIOS plus récent mais ne peuvent pas flasher sans CPU pris en charge installé. Piège parfait : vous avez besoin du CPU pour démarrer et flasher le BIOS, et vous avez besoin du BIOS pour démarrer le CPU.

5) Oscillation de performance : les horloges rebondissent, pics de latence

Cherchez des conflits de gestion de l’énergie : gouverneur du noyau, C-states du BIOS, CPPC, politiques turbo ou throttling thermique. Les réglages « auto » sont rarement une politique stable ; ce sont des techniques de vente.

6) Comportement étrange en virtualisation après échange de CPU

Les nouvelles fonctionnalités CPU peuvent modifier les ensembles d’instructions exposés aux VM. La migration à chaud peut échouer. Les licences ou flags de fonctionnalité peuvent se casser. Certains environnements exigent un masquage de fonctionnalités CPU pour garder les clusters cohérents.

Plan de diagnostic rapide

Quand la mise à niveau est déjà faite et que le système se comporte mal, vous n’avez pas le temps pour un séminaire philosophique. Il faut trouver le goulot d’étranglement et décider s’il faut revenir en arrière, patcher ou reconfigurer.

Première question : est-ce du throttling puissance/thermique ?

• Vérifiez les fréquences actuelles et maximales sous charge.
• Vérifiez les flags de throttling (là où disponibles) et les capteurs de température CPU.
• Corrélez le throttling avec les phases de la charge (AVX, compression, rafales).

Deuxième question : est-ce un décalage microcode/firmware ou des retombées d’errata ?

• Confirmez la version du BIOS, la révision du microcode et l’état du microcode dans le noyau.
• Vérifiez les logs pour MCE/WHEA, EDAC et événements PCIe AER.
• Comparez le comportement entre hôtes identiques — si un seul hôte est « spécial », il est probablement lui le problème.

Troisième question : est-ce la stabilité du training mémoire / contrôleur IMC ?

• Cherchez les corrections ECC, compteurs EDAC et MCE liés à la mémoire.
• Réduisez la vitesse mémoire (ou désactivez XMP/DOCP) comme test, pas comme mode de vie.
• Exécutez un test de stress mémoire contrôlé pendant la fenêtre de changement, pas après.

Quatrième question : le planificateur/ la topologie OS est-il maintenant incorrect ?

• Validez le nombre de cœurs, l’état SMT, les nœuds NUMA et les réglages d’isolation CPU.
• Sur les architectures hybrides, validez le support du noyau et la politique d’affinité.
• En virtualisation, confirmez les masques de fonctionnalités CPU et la compatibilité du cluster.

Si vous ne pouvez pas expliquer le comportement en 30 minutes avec ces vérifications, vous êtes passés du « tuning » au « rollback et réévaluation ». Ce n’est pas une défaite. C’est l’âge adulte.

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

Ces tâches sont centrées sur Linux parce que Linux a tendance à dire la vérité (finalement). Utilisez-les lors des vérifications préalables et de la validation post-mise à niveau. Chaque tâche inclut : commande, signification de la sortie et décision à prendre.

Task 1: Identify the CPU model, stepping, and microcode revision

cr0x@server:~$ lscpu | egrep 'Model name|Socket|Stepping|CPU\(s\)|Thread|Core|NUMA|Vendor|Flags'
Vendor ID:                       GenuineIntel
Model name:                      Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
CPU(s):                          44
Thread(s) per core:              2
Core(s) per socket:              22
Socket(s):                       1
Stepping:                        1
NUMA node(s):                    1
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr ... avx2

Signification : Confirme la topologie (cœurs/threads/sockets), le stepping et les flags de fonctionnalités. Le stepping compte pour le support BIOS et le comportement d’errata.

Décision : Si le stepping diffère de votre flotte validée, traitez-le comme une nouvelle variante de plateforme. Mettez à jour le runbook et testez la migration/masquage de fonctionnalités en virtualisation.

cr0x@server:~$ grep -m1 -E 'microcode|model|stepping' /proc/cpuinfo
model		: 79
stepping	: 1
microcode	: 0xb00003e

Signification : Affiche la révision de microcode en cours d’utilisation maintenant.

Décision : Si cela diffère des autres hôtes sur le même BIOS/noyau, vous avez de la dérive. Corrigez la dérive avant de blâmer l’application.

Task 2: Verify BIOS/UEFI version (and vendor strings)

cr0x@server:~$ sudo dmidecode -t bios | egrep 'Vendor|Version|Release Date|BIOS Revision'
Vendor: American Megatrends Inc.
Version: 3.2
Release Date: 08/17/2022
BIOS Revision: 5.27

Signification : C’est l’identité du firmware que vous corrélerez avec les comportements connus comme bons.

Décision : Si la mise à niveau requérait une montée de BIOS, assurez-vous que tout le cluster est sur la même base sauf si vous avez explicitement conçu la gestion de l’hétérogénéité.

Task 3: Confirm whether microcode was loaded by the kernel

cr0x@server:~$ dmesg -T | egrep -i 'microcode|ucode' | tail -n 5
[Tue Feb  4 10:22:11 2026] microcode: microcode updated early to revision 0xb00003e, date = 2023-10-12
[Tue Feb  4 10:22:11 2026] microcode: CPU0: patch_level=0x00000000

Signification : « updated early » indique que le microcode livré par l’OS (initramfs) a été appliqué avant la plupart du noyau. C’est généralement ce que vous souhaitez.

Décision : Si le microcode n’est pas appliqué tôt (ou pas du tout), corrigez votre package/configuration initramfs microcode. Ne faites pas tourner des CPU à moitié patchés en production.

Task 4: Look for machine check errors (MCE) and corrected hardware errors

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'mce|machine check|hardware error|whea|edac' | tail -n 20
Feb 04 10:41:12 server kernel: mce: [Hardware Error]: CPU 3: Machine Check: 0 Bank 6: b200000000070005
Feb 04 10:41:12 server kernel: mce: [Hardware Error]: TSC 0 ADDR fef1a140 MISC d012000100000000 SYND 4d000000 IPID 60000000000000
Feb 04 10:41:12 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0

Signification : Les entrées MCE/EDAC signifient que la plateforme voit et corrige (ou échoue à corriger) des erreurs. Après une mise à niveau CPU, c’est souvent du training mémoire ou une alimentation/power marginale.

Décision : Si vous voyez de nouvelles erreurs corrigées post-upgrade, arrêtez. Enquêtez avant d’étendre le déploiement. Les erreurs corrigées sont un système d’alerte précoce, pas une entrée de log décorative.

Task 5: Check CPU frequency behavior and current governor

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

Signification : Montre le gouverneur pour cpu0 (généralement représentatif). « performance » maintient des horloges plus élevées ; « powersave » peut encore booster sur les CPU modernes mais les politiques varient.

Décision : Si vous poursuivez des régressions de latence, verrouillez une politique connue et testez. Ne laissez pas le comportement du gouverneur implicite sur une flotte.

cr0x@server:~$ grep -E 'cpu MHz|model name' -m3 /proc/cpuinfo
model name	: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
cpu MHz		: 1200.000
model name	: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz

Signification : Instantané de la fréquence effective actuelle. Les chiffres à l’arrêt ne prouvent pas un throttling ; vérifiez sous charge.

Décision : Si sous charge les fréquences plafonnent en dessous du turbo all-core attendu, suspectez d’abord les limites de puissance ou les thermiques avant de blâmer le microcode.

Task 6: Check temperature sensors and throttling hints

cr0x@server:~$ sudo sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +78.0°C  (high = +80.0°C, crit = +100.0°C)
Core 0:        +76.0°C  (high = +80.0°C, crit = +100.0°C)
Core 1:        +77.0°C  (high = +80.0°C, crit = +100.0°C)

Signification : Si vous êtes sur la valeur « haute » pendant une charge normale, vous vivez sur du temps emprunté. Les CPU serveurs se protégeront ; vos SLO ne le feront pas.

Décision : Améliorez le refroidissement, réduisez les limites de puissance ou changez le SKU CPU. Ne « résolvez » pas ça en prétendant que les capteurs sont pessimistes.

Task 7: Inspect power limit behavior via RAPL (Intel) when available

cr0x@server:~$ sudo powercap-info -p intel-rapl
Zone 0
  Name: package-0
  Power limits:
    long_term: 140.00 W (enabled)
    short_term: 180.00 W (enabled)

Signification : Montre les limites de puissance configurées du package. Elles influencent fortement la fréquence soutenue.

Décision : Si les limites sont plus basses que ce que vous attendiez pour le CPU et le châssis, ajustez dans le BIOS vers une politique validée. Si votre VRM/refroidissement ne peut pas gérer plus, c’est aussi votre réponse.

Task 8: Detect thermal throttling and frequency caps via kernel messages

cr0x@server:~$ dmesg -T | egrep -i 'thrott|thermal|power limit' | tail -n 20
[Tue Feb  4 11:02:03 2026] CPU0: Core temperature above threshold, cpu clock throttled (total events = 12)
[Tue Feb  4 11:02:03 2026] CPU0: Package temperature above threshold, cpu clock throttled (total events = 12)

Signification : Le noyau rapporte des événements de throttling thermique. Ce n’est pas « normal ». C’est le CPU qui demande un plan moins ambitieux.

Décision : Si le throttling se produit pendant une charge en régime permanent, traitez-le comme une perte de capacité. Corrigez le refroidissement ou limitez le turbo/la puissance dans le BIOS pour une performance prévisible.

Task 9: Validate memory speed and configuration post-upgrade

cr0x@server:~$ sudo dmidecode -t memory | egrep -A3 'Memory Device|Speed:|Configured Memory Speed:|Manufacturer:|Part Number:' | head -n 40
Memory Device
	Manufacturer: Samsung
	Part Number: M393A2K40BB1-CRC
	Speed: 2400 MT/s
	Configured Memory Speed: 2133 MT/s

Signification : Montre la vitesse nominale des DIMM vs la vitesse configurée. Une mise à niveau CPU peut changer les multiplicateurs mémoire supportés, ou le BIOS peut rétrograder pour la stabilité.

Décision : Si la vitesse configurée a chuté de façon inattendue, vérifiez les vitesses supportées par l’IMC du CPU avec votre population de DIMM. La stabilité vaut mieux que la bande passante théorique, mais des downclocks inattendus expliquent des régressions de performance.

Task 10: Check PCIe errors after platform changes

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'aer|pcie|corrected error' | tail -n 20
Feb 04 10:55:21 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
Feb 04 10:55:21 server kernel: pcieport 0000:00:1c.0: AER: [ 0] RxErr

Signification : Les erreurs PCIe AER corrigées peuvent apparaître après des changements CPU/BIOS (training PCIe, intégrité de signal, politiques ASPM).

Décision : Quelques-unes au démarrage peuvent être tolérables ; des occurrences persistantes sous charge ne le sont pas. Enquêtez les réglages PCIe du BIOS, reseatez les cartes, vérifiez risers/câbles et envisagez des mises à jour firmware des endpoints.

Task 11: Confirm NUMA layout and CPU topology (important for perf regressions)

cr0x@server:~$ numactl --hardware
available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
node 0 size: 257761 MB
node 0 free: 244120 MB

Signification : Confirme les nœuds NUMA et le mapping CPU. Une mise à niveau CPU (ou un reset BIOS) peut changer le comportement NUMA, l’interleaving mémoire ou le SNC (sub-NUMA clustering).

Décision : Si la disposition NUMA a changé par rapport à votre baseline, revisitez le pinning, l’allocation hugepages et les hypothèses de localité mémoire.

Task 12: Confirm virtualization CPU feature exposure (KVM example)

cr0x@server:~$ sudo virsh capabilities | egrep -n 'model|vendor|feature' | head -n 25
12:    Intel
18:    Broadwell
19:    
20:    
21:    

Signification : Montre ce que l’hôte annonce. Après une mise à niveau CPU, le modèle/fonctionnalités peuvent différer, brisant la compatibilité de migration à chaud.

Décision : Si vous dépendez de la migration, imposez un modèle CPU cohérent (masquage). « Ça démarre » n’est pas le test d’acceptation pour la virtualisation.

Task 13: Check kernel mitigations state (performance regression clue)

cr0x@server:~$ grep . /sys/devices/system/cpu/vulnerabilities/* | head -n 20
/sys/devices/system/cpu/vulnerabilities/spectre_v1: Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2: Mitigation: Retpolines; IBPB: conditional; IBRS_FW; STIBP: disabled; RSB filling

Signification : Montre quelles atténuations sont actives. Les microcode et mises à jour BIOS peuvent changer cela sans vous prévenir gentiment.

Décision : Si la performance a régressé, quantifiez-la et décidez avec la sécurité si le niveau d’atténuation est acceptable. Ne désactivez pas en secret des atténuations pour gagner un bench contre vous-même.

Task 14: Stress test in a controlled way (and watch errors)

cr0x@server:~$ sudo stress-ng --cpu 0 --cpu-method matrixprod --metrics-brief --timeout 120s
stress-ng: info:  [27184] setting to a 120s run per stressor
stress-ng: info:  [27184] dispatching hogs: 44 cpu
stress-ng: info:  [27184] successful run completed in 120.00s
stress-ng: info:  [27184] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: info:  [27184] cpu             1234567   120.00   5100.00     12.34     10288.06

Signification : Une charge CPU répétable. Associez-la à la surveillance des capteurs et des logs pour faire remonter le throttling ou les erreurs pendant la fenêtre.

Décision : Si le stress provoque du throttling ou des événements MCE/EDAC, la mise à niveau n’est pas prête pour la production. Corrigez d’abord puissance/refroidissement/BIOS.

Trois mini-récits d’entreprise issus du champ miné des mises à jour

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

L’entreprise disposait d’une petite flotte de serveurs 1U « identiques » utilisés pour des pipelines de build. Même châssis, même révision de carte, même PSU. Ils avaient une pile de mises à niveau CPU plus rapides dans un placard — pièces plus rapides, même socket, même génération. La demande de changement a été traitée comme routinière : mise à niveau en rolling, un hôte à la fois, pas de changements au niveau applicatif.

Le premier hôte mis à niveau a démarré et a réintégré le pool. Les builds ont tourné pendant quelques heures puis l’hôte a redémarré brutalement sous une compilation parallèle maximale. Pas de panique, pas de logs au-delà des dernières lignes. Il est revenu, a réintégré et a planté à nouveau. L’équipe a supposé un CPU défectueux et l’a remplacé. Même comportement. Puis ils ont blâmé le PSU. Puis le noyau parce que c’est ce que nous faisons quand nous sommes fatigués.

Finalement, quelqu’un a remarqué que le comportement turbo du CPU mis à niveau était différent : les rafales courtes allaient bien, la charge soutenue déclenchait une consommation all-core plus élevée que l’ancien SKU n’avait jamais demandée. Le dissipateur VRM de la carte mère avait été conçu pour les SKU validés originaux, et le profil d’écoulement d’air du châssis n’était pas bon au coin des VRM. Sous des builds parallèles soutenus, la température du VRM augmentait silencieusement jusqu’à ce que la protection se déclenche — reset instantané.

La mauvaise hypothèse était « même socket signifie même profil de puissance ». La compatibilité de socket est une exigence de démarrage, pas une garantie opérationnelle. Ils ont résolu le problème en plafonnant les limites de puissance dans le BIOS à une enveloppe testée et en augmentant la courbe des ventilateurs du châssis pour ce pool. La solution finale fut l’approvisionnement : arrêter d’acheter la variante de carte la moins chère pour des rôles intensifs CPU.

Mini-récit 2 : L’optimisation qui a mal tourné

Une autre équipe exécutait des services à faible latence sur bare metal. Après une mise à niveau CPU, ils ont constaté que leur p99 de latence empirait lors des pics de trafic. L’utilisation CPU semblait correcte. La charge moyenne n’alertait pas. La première hypothèse de tout le monde fut « pauses GC » ou « jitter réseau ». Ils ont commencé à tuner les threads applicatifs et à pinner les cœurs. Ils ont même envisagé de réécrire un chemin chaud parce que c’était le genre de semaine que c’était.

Un ingénieur performance a repéré quelque chose dans la surveillance : la fréquence oscillait sous charge en rafales. Le nouveau BIOS avait « enhanced turbo » activé par défaut, ce qui supprimait essentiellement des limites de puissance sensées. Le CPU augmentait vite la fréquence, atteignait rapidement les limites thermiques, puis bridait. Le résultat n’était pas une baisse de performance moyenne ; c’était une performance incohérente. La latence déteste l’incohérence plus que des horloges modestement plus basses.

Ils ont « optimisé » en activant la politique de boost la plus agressive parce que cela brillait dans un benchmark. En production, cela a produit un motif en dents de scie : boost, surchauffe, throttle, récupération, répétition. Le noyau a ensuite déplacé le travail vers des cœurs « plus rapides », ce qui a changé la localité du cache et aggravé la latence de queue.

La correction fut ennuyeuse : définir explicitement PL1/PL2/Tau sur un profil stable que le refroidissement pouvait soutenir, et verrouiller les courbes de ventilateurs. La latence s’est améliorée immédiatement, et l’équipe a arrêté de discuter avec la réalité. Ils ont laissé un peu de débit de pointe de côté. Ils ont gagné de la prévisibilité, ce que les clients remarquent réellement.

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

Une équipe de stockage a planifié des mises à niveau CPU pour un ensemble de nœuds gourmands en chiffrement. Ils avaient appris — à la douleur — que « petits changements de firmware » ne sont pas petits. Alors ils ont traité la mise à niveau comme un changement de plateforme : préflight, canari, rollout, postflight, avec un plan de rollback strict.

Ils ont commencé par inventorier les versions BIOS, les révisions de microcode et les populations de DIMM à travers la flotte. Ils ont découvert de la dérive : une poignée de nœuds avait un BIOS plus récent parce que quelqu’un avait remplacé une carte mère sous garantie et n’avait pas standardisé le firmware ensuite. Cette dérive n’avait jamais compté — jusqu’à ce qu’une mise à niveau CPU la rende significative à l’échelle.

Ils ont choisi un hôte canari, mis à jour le BIOS vers la baseline cible, validé le chargement du microcode dans l’initramfs et exécuté une suite de stress contrôlée incluant des tests AVX lourds et une pression I/O. Ils ont surveillé les compteurs EDAC et les logs PCIe AER comme s’il s’agissait d’un moniteur cardiaque. L’hôte a passé, mais seulement après qu’ils aient ajusté la vitesse mémoire d’un cran vers le bas à cause d’une instabilité de training avec les DIMMs existants.

Lors du déploiement, un nœud n’a pas POSTé après l’échange de CPU. Au lieu d’improviser, ils ont exécuté la procédure de rollback : remettre l’ancien CPU, démarrer, flasher le BIOS à nouveau, effacer la NVRAM et retenter. Ça a marché. L’incident a été contenu parce que le plan supposait des bizarreries et autorisait les gens à arrêter et revenir en arrière.

Ils n’ont pas eu d’histoire héroïque à raconter. Ils ont eu une semaine tranquille. C’est le résultat correct.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: Random reboots only during heavy compute

Cause racine : Surchauffe des VRM ou protection overcurrent, souvent déclenchée par AVX soutenu ou boost all-core.

Correction : Plafonnez les limites de puissance dans le BIOS à ce que la carte et le refroidissement peuvent soutenir ; améliorez le flux d’air des VRM ; évitez les défauts « multi-core enhancement/unlimited turbo ».

2) Symptom: CPU is “faster” on paper but throughput is worse

Cause racine : Limites de puissance conservatrices (PL1 trop bas), throttling thermique, ou atténuations activées par un microcode/BIOS plus récent.

Correction : Mesurez les horloges sous charge ; définissez des limites de puissance explicites ; assurez le refroidissement ; comparez l’état des atténuations ; prenez une décision consciente sécurité/performance.

3) Symptom: POST failure after CPU swap

Cause racine : Le BIOS ne supporte pas le CPU, ou les réglages NVRAM incompatibles avec le nouveau stepping, ou une régression de training mémoire.

Correction : Mettez à jour le BIOS en utilisant d’abord un CPU connu-supporté ; effacez CMOS/NVRAM ; réduisez temporairement la vitesse mémoire et retirez les DIMMs marginaux pour compléter le training.

4) Symptom: New corrected memory errors (ECC) after upgrade

Cause racine : Différences du contrôleur mémoire, algorithmes de training modifiés dans un nouveau BIOS, intégrité de signal DIMM marginale, ou conditions instables VDD/Vcore.

Correction : Abaissez la vitesse mémoire ; assurez-vous que les DIMMs respectent les règles de population ; mettez à jour le BIOS ; validez avec un stress mémoire ; remplacez les DIMMs suspects si les erreurs suivent une barrette.

5) Symptom: Live migration fails after CPU upgrade

Cause racine : L’ensemble de fonctionnalités CPU a changé ; le cluster n’est plus homogène ; l’hyperviseur refuse la migration à cause d’un mismatch.

Correction : Configurez des baselines de modèle CPU et des masques de fonctionnalités ; standardisez microcode/BIOS dans le cluster ; validez les chemins de migration avant le rollout.

6) Symptom: Intermittent PCIe device errors after upgrade

Cause racine : Changements de training PCIe, toggles ASPM, modifications des défauts BIOS, ou sensibilité du firmware de l’endpoint.

Correction : Vérifiez les logs AER ; reseatez le matériel ; définissez des paramètres PCIe connus-bons dans le BIOS ; mettez à jour le firmware des endpoints si approprié ; échangez risers/câbles.

7) Symptom: Fans louder and still throttling

Cause racine : Solution de refroidissement insuffisante pour le nouveau comportement de puissance soutenue ; pâte thermique ou montage incorrect après réinstallation.

Correction : Reposez le dissipateur, confirmez le contact ; respectez le couple de serrage ; validez le flux d’air ; définissez des limites de puissance stables plutôt que de courir après des pics de boost.

8) Symptom: Kernel logs show “microcode updated” and performance changes unexpectedly

Cause racine : La révision du microcode diffère entre hôtes, ou un nouveau microcode change les atténuations/errata.

Correction : Standardisez les versions de package microcode ; intégrez-les dans les images gold ; surveillez la révision du microcode comme élément de configuration ; déployez-le comme une mise à jour de noyau.

Blague #2 : « Auto » dans le BIOS signifie « surprises automatiques ». C’est l’équivalent firmware de laisser un enfant conduire parce qu’il est enthousiaste.

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

Checklist pré-mise à niveau : décidez si la mise à niveau est même une bonne idée

1. Confirmez le support plateforme : liste de support CPU du vendeur de la carte par SKU exact et stepping, pas seulement la génération marketing.
2. Confirmez le chemin firmware : version BIOS cible, disponibilité de downgrade/rollback et méthode de flash (in-band vs out-of-band).
3. Confirmez l’alimentation et le refroidissement : adéquation de conception VRM, flux d’air du châssis, classe de dissipateur et marge PSU.
4. Confirmez les règles de population mémoire : mix rang/tailles DIMM, vitesse et si le SKU CPU change les taux mémoire supportés.
5. Confirmez les caractéristiques de la charge : intensité AVX, charge all-core soutenue, trafic sensible à la latence en rafales, ou I/O + CPU mixte.
6. Confirmez les contraintes de virtualisation : baseline/masquage CPU, compatibilité de migration, liens de licence au modèle CPU le cas échéant.

Plan de fenêtre de changement : exécutez comme si vous attendiez des problèmes

1. Inventaire et baseline : capturez BIOS, microcode, noyau, état des atténuations et métriques de performance clés.
2. Standardisation firmware d’abord : mettez à jour le BIOS/UEFI vers la cible sur le CPU existant si nécessaire, validez le boot et les logs.
3. Canari un hôte : ne pas mettre à niveau par lots. Un seul hôte, une passe complète de validation.
4. Installez le CPU : suivez les consignes ESD et de couple. Reseat la mémoire si vous l’avez touchée. Ne « nettoyez et réutilisez la pâte » comme en 1999.
5. Vérifications du premier démarrage : confirmez l’ID CPU, la révision microcode, la vitesse mémoire et l’absence de nouveaux MCE/EDAC/AER.
6. Stress contrôlé : exécutez stress CPU + mémoire et surveillez temps, horloges et logs d’erreurs en temps réel.
7. Test fumée de la charge : exécutez une charge représentative ou un synthétique correspondant à votre goulot (crypto, compression, compilation, JVM, base de données).
8. Point de décision rollback : si vous voyez des erreurs corrigées, du throttling ou de l’instabilité, revenez en arrière. Ne négociez pas avec un avertissement.

Checklist post-mise à niveau : évitez les incidents lents

1. Verrouillez la configuration : documentez les réglages BIOS importants (limites de puissance, C-states, SMT, profil mémoire, réglages PCIe).
2. Surveillez les bons compteurs : MCE/EDAC, PCIe AER, événements de throttling, distributions de fréquence et tendances de température.
3. Standardisez la livraison du microcode : assurez-vous que les packages initramfs microcode sont cohérents sur la flotte.
4. Revisitez les modèles de capacité : mettez à jour les baselines de performance et les seuils de marge en utilisant la performance soutenue observée, pas les pics de boost.
5. Mettez à jour les règles de compatibilité du cluster : baselines hyperviseur CPU, masques de fonctionnalités et politique de migration.

Plan de rollback (écrivez-le avant d’en avoir besoin)

• Gardez au moins un CPU connu-bon sur site pour les chemins de récupération BIOS.
• Conservez les images de flash BIOS pour les versions actuelles et cibles, et sachez quelle direction est autorisée.
• Capturez les réglages BIOS (photos, export ou texte quand possible) avant le changement.
• Définissez des « conditions d’arrêt » : tout nouveau MCE, montée des taux CE EDAC, throttling thermique en charge soutenue, ou resets inexpliqués.

FAQ

1) If the motherboard socket matches, why can’t I assume it will work?

Parce que la compatibilité de socket est une compatibilité physique. La compatibilité opérationnelle requiert un support firmware, un microcode stable, une alimentation correcte et un training mémoire validé pour ce stepping CPU.

2) Should I update BIOS before or after installing the new CPU?

Avant, quand c’est possible. Mettez à jour le BIOS sur l’ancien CPU, vérifiez la stabilité, puis échangez les CPU. Cela réduit les variables et évite le piège « impossible de flasher sans un CPU plus ancien pris en charge ».

3) Is OS-delivered microcode enough, or do I need a BIOS update too?

Souvent vous avez besoin des deux. Les mises à jour BIOS peuvent inclure du code d’init CPU, des correctifs de training mémoire et des réglages plateforme que l’OS ne peut pas remplacer. Le microcode OS seul ne résoudra pas tout ce que contrôle le BIOS.

4) Can microcode updates reduce performance?

Oui, selon les atténuations et les contournements d’errata. La bonne approche est de mesurer et décider consciemment, pas de prétendre que cela ne peut pas arriver.

5) How do I tell if VRM limits are the problem?

Cherchez des redémarrages sous charge soutenue, du throttling puissance/thermique et un schéma où des tests courts passent mais des runs longs échouent. Sur certaines plateformes vous pouvez observer des événements de throttling et les corréler avec températures et limites de puissance.

6) Why does “auto” BIOS power behavior differ across boards?

Parce que les vendeurs paramètrent « auto » pour des objectifs différents : gains de benchmark, cibles acoustiques, marges thermiques ou stabilité conservatrice en entreprise. « Auto » n’est pas une norme ; c’est une personnalité.

7) What’s the safest way to roll out CPU upgrades in a cluster?

Standardisez le firmware d’abord, canarisez un hôte, exécutez des tests de stress + charges représentatives, puis déployez progressivement tout en surveillant les compteurs d’erreurs matérielles et les distributions de performance.

8) Do I need to worry about memory speed after a CPU upgrade?

Oui. Le contrôleur mémoire du CPU et le code de training du BIOS interagissent. Un nouveau stepping CPU ou un nouveau BIOS peut changer ce qui est stable à une population de DIMM donnée. Validez la vitesse configurée et surveillez EDAC.

9) Can a CPU upgrade break virtualization live migration?

Absolument. De nouvelles fonctionnalités CPU peuvent apparaître, et les hyperviseurs peuvent refuser les migrations entre ensembles de fonctionnalités non assortis. Utilisez des baselines/masques CPU et maintenez la cohérence du cluster.

10) When should I stop debugging and just roll back?

Si vous voyez de nouvelles erreurs matérielles corrigées, du throttling thermique en charge normale ou des resets inexpliqués. Revenez en arrière, rébaselinez et réabordez avec des variables contrôlées.

Étapes suivantes pour rester employable

Les mises à niveau CPU ne sont pas « swap and go ». Traitez-les comme un changement de plateforme, parce que c’en est un. Voici le chemin pratique à suivre :

1. Choisissez votre résultat cible : la performance soutenue et la stabilité valent mieux que les chiffres de boost de pointe. Écrivez-le dans la demande de changement.
2. Standardisez firmware et microcode : décidez vos baselines, puis éliminez la dérive. L’inventaire n’est pas optionnel.
3. Rendez la politique de puissance explicite : fixez limites de puissance et politique de refroidissement à une enveloppe connue-bonne. Ne laissez pas « auto » définir votre SLO.
4. Utilisez canaris et conditions d’arrêt : un hôte ne prouve rien ; un hôte en échec vous en dit long. Repliez-vous tôt et sans honte.
5. Instrumentez ce qui compte : MCE/EDAC/AER, événements de throttling, distribution de fréquence sous charge et températures. Si vous ne pouvez pas le voir, vous ne pouvez pas l’exploiter.

Si vous faites ces cinq choses, la mise à niveau CPU cesse d’être un pari et devient un changement que vous pouvez défendre — techniquement, opérationnellement et devant une salle de collègues sceptiques.