LGA vs PGA : pourquoi les broches ont migré vers la carte mère

LGA vs PGA en une page : termes, anatomie et ce qui touche réellement quoi

PGA (Pin Grid Array)

Dans le PGA, le boîtier du CPU comporte un réseau de broches qui sortent de lui. La carte mère a un socket avec
des trous correspondants (et des contacts à ressort internes) qui saisissent ces broches.
Vous insérez le CPU, fermez un levier (ZIF : Zero Insertion Force), et le socket s’agrippe aux broches.

L’avantage visible pour l’utilisateur du PGA est évident : le socket de la carte mère est principalement un réceptacle
passif en plastique+métal. Si vous endommagez les broches, vous pouvez parfois les redresser. Si vous anéantissez le socket,
vous achetez une nouvelle carte de toute façon. Mais le PGA fait du « dommage » un problème côté CPU plus souvent.

LGA (Land Grid Array)

Dans le LGA, le CPU a des plots plats (« lands ») en dessous. Le socket de la carte mère a des broches à ressort qui
appuient contre ces plots. Une plaque de charge et un levier fournissent la force de serrage pour que la pression de contact
soit cohérente sur des centaines ou milliers de contacts.

L’avantage du LGA est surtout invisible jusqu’à ce que vous fassiez fonctionner des bus rapides et des nombreux cœurs :
il supporte des comptes de broches plus élevés et de meilleures caractéristiques électriques à haute fréquence.
Le compromis est que les éléments fragiles (les broches) résident maintenant sur la carte mère. Les plier signifie peut-être
remplacer une carte qui coûte plus que le CPU que vous essayiez de « sauver ».

Ce que sont réellement les « broches » : des contacts, pas de la magie

Que ce soit PGA ou LGA, le travail électrique est le même : un contact contrôlé à faible résistance avec
une inductance et une capacitance prévisibles, stable à travers les cycles de température, les vibrations et le temps.
Les plateformes modernes ont besoin de cela pour :

• Alimentation et masses (une grande partie des « broches » servent juste à livrer du courant et des chemins de retour).
• Liaisons série haute vitesse (PCIe, UPI/QPI, interconnexions de type Infinity Fabric).
• Canaux mémoire (DDR4/DDR5 : sensibles au timing et au bruit).
• Signaux secondaires (SMBus, interface SPI flash, debug, management).

Vous ne « perdez » pas une broche. Vous perdez une fonction : un canal mémoire, un groupe de lanes PCIe, un bus de management,
ou la stabilité sous charge. C’est pourquoi la panne ressemble à un problème logiciel jusqu’à ce que ce ne soit plus le cas.

Pourquoi les broches ont bougé : densité, intégrité du signal et réalité mécanique

Densité de broches : le dictateur discret

Le nombre de connexions qu’un CPU moderne nécessite a explosé. Pas parce que le marketing voulait des sockets plus gros,
mais parce que la physique exigeait plus d’alimentation et plus d’E/S. Des comptes de cœurs élevés et des puissances turbo
importantes demandent des courants sérieux. Le courant exige du métal. Le métal exige de la surface. La surface exige des broches/contacts.

Les broches PGA ont des limites pratiques : le pas (espacement) des broches ne peut pas diminuer indéfiniment sans que les broches
deviennent trop fragiles, trop faciles à plier, ou trop susceptibles de faire court-circuit. Les sockets LGA peuvent empaqueter
les contacts plus densément car la « broche » est un élément à ressort côté socket, et le CPU n’a que des plots.
Le boîtier CPU n’a pas besoin d’aiguilles dépassantes qui doivent survivre au transport, à la manutention et à l’installation.

Intégrité du signal : à haute vitesse, la géométrie est la règle

Quand les bus fonctionnent en territoire multi-gigahertz, la géométrie du contact compte. Pas de manière académique.
De manière « votre lien PCIe s’entraîne en Gen4 au lieu de Gen5 et votre débit de stockage s’effondre ». Le LGA tend à offrir
un meilleur contrôle de :

• Inductance : des structures de contact plus courtes et plus plates réduisent les effets inductifs.
• Consistance d’impédance : les sockets sont conçus pour garder les transitions plus propres.
• Chemins de retour : plus de contacts de masse et une meilleure distribution améliorent les marges de bruit.
• Diaphonie : un meilleur contrôle du couplage voisin aide à maintenir les ouvertures d’œil.

Les broches PGA sont de petits antennes. Elles peuvent très bien fonctionner, mais à mesure que les vitesses et les densités augmentent,
le « très bien » se transforme en « nous passons trop de temps d’ingénierie à le rendre bien ».

Alimentation : plus de masses que vous ne le pensez

Les CPU modernes tirent des courants importants et changeants rapidement. Le boîtier et le socket doivent fournir de l’énergie
avec une faible impédance sur une large bande de fréquences. Cela signifie de nombreux contacts d’alimentation/masse répartis
pour réduire les points chauds locaux et la chute de tension. Le LGA facilite l’allocation d’un grand nombre de contacts
tout en conservant une fiabilité mécanique raisonnable.

Charge mécanique et fiabilité du contact

Les sockets LGA utilisent une plaque de charge et un levier pour appliquer une force définie. Cette force compte : trop faible,
vous obtenez des contacts intermittents (le pire type). Trop forte, vous risquez la flexion de la carte ou des dégâts au socket.
Dans un système LGA bien conçu, la pression est uniforme et prévisible. C’est difficile à garantir avec des broches PGA en grand nombre
sans rendre l’insertion et la rétention cauchemardesques.

Première blague courte (comme promis, seulement deux) : Un socket LGA est comme un lecteur de badge de datacenter — touchez parfaitement
les plots ou rien ne se passe, et il se souvient de vos erreurs pour longtemps.

Fabrication et rendement : quel côté est moins coûteux à protéger ?

C’est la partie que les ingénieurs ne disent pas toujours à voix haute devant les clients : déplacer la géométrie fragile
du CPU vers le socket change l’économie. Les boîtiers CPU sont chers, des éléments de grande valeur.
Les cartes mères sont aussi chères, mais les sockets peuvent être intégrés à la fabrication de la carte et testés
de manières différentes.

Avec le LGA, le dessous du CPU est un réseau plat de plots plus facile à protéger avec un couvercle et moins susceptible
d’être plié pendant l’expédition. Les broches fragiles sont sur la carte, généralement protégées par un capot de socket
jusqu’à l’installation. Sur le terrain, cela pousse la défaillance vers la « manutention à l’installation » plutôt que
la « casse en expédition ». Ce n’est pas plus gentil. C’est plus maîtrisable.

Faits intéressants et contexte historique (9 points rapides)

1. Intel grand public est passé au LGA au milieu des années 2000 (ère LGA775), poussé par des comptes de broches et des besoins d’alimentation plus élevés.
2. AMD est resté plus longtemps avec le PGA sur les plateformes grand public (ex. AM2/AM3/AM4), en partie pour la longévité du socket et la stabilité de l’écosystème.
3. Les sockets serveurs sont devenus « gros LGA » tôt parce que les interconnexions multi-socket et plus de canaux mémoire exigent beaucoup de contacts.
4. La plupart des contacts ne sont pas des « signaux » : une large fraction sert à l’alimentation et à la masse pour gérer la livraison de courant et le bruit.
5. Le LGA permet un pas plus dense parce que le contact à ressort est côté socket et peut être fabriqué avec des tolérances plus serrées que des broches CPU saillantes.
6. Les couvercles de socket existent pour une raison : laisser un socket LGA découvert pendant la manutention, c’est inviter un petit drame mécanique.
7. Le placage des contacts compte : placage or et matériaux de ressort choisis pour minimiser la corrosion et maintenir une résistance de contact stable sur les cycles.
8. « Canal mémoire manquant » est un symptôme classique : un ou plusieurs contacts d’adresse/données/contrôle qui ne font pas bon contact.
9. Échecs d’entraînement PCIe génération après génération peuvent être causés par des contacts limites ; le lien rétrograde à une vitesse inférieure qui « fonctionne » mais réduit silencieusement le débit.

La vérité inconfortable : le LGA est meilleur pour la performance ; le PGA est plus indulgent pour les humains

Si vous concevez une plateforme avec une densité d’E/S élevée et une puissance importante, le LGA est le choix pragmatique.
Si vous êtes un technicien qui change des CPU à la hâte, le PGA est plus sympathique — car votre ennemi, ce sont vos propres mains,
pas les broches microscopiques à ressort du socket.

Modes de défaillance pertinents en production

Broches LGA pliées : le cauchemar « ça boot, mais… »

Les dommages LGA sont souvent partiels. Quelques broches ne font pas contact, et le système s’allume quand même.
Vous entrez alors dans le pays des bizarreries :

• Un canal mémoire manquant, ou la RAM fonctionne à une vitesse inférieure.
• Des périphériques PCIe disparaissent ou rétrogradent leur entraînement (Gen5 → Gen4 → Gen3).
• Exceptions Machine Check (MCE) sous charge, surtout lors de charges mémoire lourdes.
• Redémarrages aléatoires corrélés à la température ou aux vibrations.
• Erreurs d’E/S sporadiques qui ressemblent à un « NVMe défectueux » mais ne le sont pas.

La raison : ces broches ne sont pas juste « en trop ». Elles sont souvent groupées par fonction. Perdre un groupe et
vous perdez tout un groupe de lanes ou un canal. Perdre une référence de masse et vous perdez l’intégrité du signal.

Broches PGA pliées : dramatique, visible et parfois réparable

Les pannes PGA sont généralement plus évidentes. Une broche se plie, le CPU ne s’insère pas, ou il s’insère mais une broche
ne s’aligne pas correctement. Vous pouvez voir :

• Pas de POST, ou POST avec codes d’erreur clairs.
• CPU non détecté.
• Mémoire non détectée, similaire au LGA, mais souvent avec une défaillance plus complète.

Et oui, parfois vous pouvez redresser les broches. Le risque est la micro-fracture et le durcissement par travail mécanique.
Vous l’obtenez « droit », il passe un boot rapide, puis casse six semaines plus tard après des cycles thermiques.
C’est le genre d’« économie » qui coûte cher.

Résistance de contact et contamination

Poussière, huiles de la peau, migration de pâte thermique et corrosion peuvent augmenter la résistance de contact.
Avec le LGA, les broches à ressort sont conçues pour essuyer légèrement la surface du plot afin de percer les films,
mais ce n’est pas magique. En serveurs, les reseats répétés peuvent aussi user le placage.

Flexion de la carte et pression de montage : le refroidisseur peut être le méchant

Des dissipateurs trop serrés, un montage inégal, ou des plaques arrières manquantes peuvent fléchir la carte mère et modifier
la distribution de la pression de contact. Le système peut passer une charge légère et s’effondrer sous AVX lourd ou trafic mémoire
parce que des contacts marginaux deviennent encore plus marginaux quand la température monte.

« C’est le CPU » vs « c’est le socket » : penser comme un SRE

Les CPU sont statistiquement fiables. Les sockets et la manutention le sont moins. Dans les incidents terrain, supposez :

• La configuration et le firmware d’abord.
• La mémoire et la distribution d’alimentation ensuite.
• Les problèmes de contact du socket quand les symptômes correspondent à des canaux/lanes spécifiques ou changent après un reseat.

Diagnostiquez avant d’échanger. Échanger est facile. Expliquer pourquoi vous avez échangé la mauvaise pièce coûteuse, ce ne l’est pas.

Playbook de diagnostic rapide : trouvez le goulot avant d’échanger des pièces

C’est le workflow qui gagne quand vous êtes chronométré. Vous n’essayez pas d’être malin ; vous essayez d’être correct rapidement, avec des preuves.

Première étape : établissez ce qui a changé et ce qui manque

1. Vérifiez les logs POST/firmware pour la population mémoire, l’entraînement PCIe, les erreurs CPU.
2. Confirmez l’inventaire : modèle CPU, microcode, BIOS, disposition DIMM, périphériques PCIe attendus.
3. Cherchez l’asymétrie : un canal spécifique manquant, un port racine PCIe absent — ça crie « contact ou groupe de lanes ».

Deuxième étape : classifiez le type de panne

1. Pas de POST : alimentation, présence CPU, dommage catastrophique du socket, BIOS incorrect, ou court-circuit.
2. POST mais dégradé : canaux/lanes manquants, PCIe downtrainé, erreurs corrigées — souvent pression de contact ou broches pliées.
3. Échec uniquement sous charge : contact marginal, instabilité VRM, ou réglages thermiques/firmware.

Troisième étape : prouver ou éliminer les problèmes de contact/socket

1. Réasserez le CPU et le refroidisseur avec le couple correct.
2. Inspectez le socket avec une loupe et un éclairage oblique.
3. Échangez des DIMM connus bons dans les emplacements du « canal manquant » ; si le canal reste absent, ce n’est pas le DIMM.
4. Vérifiez si le comportement change avec différents périphériques/slots PCIe ; une absence persistante du port racine pointe vers le mapping CPU-socket.

Quatrième étape : seulement alors commencez à échanger les pièces coûteuses

Si vous ne parvenez pas à stabiliser la plateforme après un reseat et une inspection soigneux, décidez si vous
remplacez la carte mère (risque LGA) ou le CPU (risque PGA) en fonction de ce qui est physiquement à risque
et de ce qui est plus facile à valider.

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

Ce sont des tâches côté Linux que vous pouvez exécuter même quand vous n’êtes pas sûr si la panne est « matérielle » ou
« logicielle ». Chaque tâche inclut : commande, ce que signifie la sortie, et la décision qu’elle permet.
L’objectif est de transformer des symptômes vagues en une hypothèse au niveau du socket.

Tâche 1 : Confirmer le modèle CPU, le stepping et le microcode chargé

cr0x@server:~$ lscpu | egrep 'Model name|Socket|Thread|Core|CPU\(s\)|Stepping'
CPU(s):                               64
Model name:                           Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz
Core(s) per socket:                   32
Thread(s) per core:                   2
Socket(s):                            1
Stepping:                             6

Sens : Si sockets/cores/threads ne correspondent pas à ce que vous avez acheté, arrêtez-vous. Ça peut être un réglage BIOS,
des cœurs désactivés, ou un CPU mal inséré/détecté.
Décision : Si le compte CPU est incorrect, priorisez les logs BIOS/POST et le reseat physique avant de chasser l’optimisation OS.

Tâche 2 : Vérifier que le noyau voit la taille de mémoire et la topologie NUMA

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 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
node 0 size: 196355 MB
node 0 free: 182904 MB
node distances:
node   0 
  0:  10

Sens : Des nœuds NUMA inattendus ou une taille mémoire significativement inférieure à la RAM installée indiquent souvent
des canaux mémoire manquants ou des emplacements DIMM désactivés.
Décision : Si la mémoire est faible, corrélez avec l’inventaire DMI ensuite ; si des emplacements semblent « vides » alors qu’ils sont physiquement peuplés, suspectez un problème de contact/channel/socket.

Tâche 3 : Inventorier les emplacements DIMM via DMI

cr0x@server:~$ sudo dmidecode -t memory | egrep -A5 'Memory Device|Locator:|Bank Locator:|Size:|Speed:|Configured Memory Speed:'
Memory Device
	Locator: DIMM_A1
	Bank Locator: P0_Node0_Channel0_Dimm0
	Size: 32768 MB
	Speed: 3200 MT/s
	Configured Memory Speed: 3200 MT/s
--
Memory Device
	Locator: DIMM_B1
	Bank Locator: P0_Node0_Channel1_Dimm0
	Size: No Module Installed
	Speed: Unknown
	Configured Memory Speed: Unknown

Sens : « No Module Installed » dans un emplacement que vous savez peuplé est un indice majeur. Si tous les emplacements
d’un canal se lisent vides, ce n’est pas une coïncidence.
Décision : Si un canal entier est manquant, prévoyez un reseat CPU + inspection du socket ; l’échange de DIMMs ne fera pas renaître un canal qui n’est pas présent électriquement.

Tâche 4 : Rechercher des erreurs du contrôleur mémoire (MCE/EDAC)

cr0x@server:~$ sudo journalctl -k | egrep -i 'mce|machine check|edac|hardware error' | tail -n 20
Jan 09 10:12:41 server kernel: EDAC sbridge MC0: HANDLING MCE MEMORY ERROR
Jan 09 10:12:41 server kernel: mce: [Hardware Error]: Machine check events logged
Jan 09 10:12:41 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Channel#2_DIMM#0 (channel:2 slot:0 page:0x12345 offset:0x0 grain:32 syndrome:0x0)

Sens : Des erreurs corrigées regroupées sur un canal ou DIMM peuvent être un problème de DIMM, mais aussi un canal marginal
(broches du socket associées à ce canal).
Décision : Si les erreurs persistent sur un canal malgré les échanges de DIMM, escaladez vers le socket/le reseating CPU plutôt que de blâmer des « lots de RAM défectueux ».

Tâche 5 : Vérifier la largeur et la vitesse du lien PCIe (détecter le downtraining)

cr0x@server:~$ sudo lspci -vv -s 3b:00.0 | egrep -i 'LnkCap:|LnkSta:'
LnkCap:	Port #0, Speed 16GT/s, Width x16, ASPM L1, Exit Latency L1 <64us
LnkSta:	Speed 8GT/s (downgraded), Width x8 (downgraded)

Sens : Le périphérique est capable de x16 à une vitesse supérieure mais fonctionne plus lent/narrow. Cela peut être :
intégrité du signal marginale, problèmes de contact de lane, riser, ou BIOS forçant la compatibilité.
Décision : Si le downtraining est stable mais inattendu, vérifiez l’emboîtage physique et la pression socket/ventirad ; s’il fluctue (change entre boots), suspectez la marginalité des contacts.

Tâche 6 : Mapper la topologie PCIe aux ports racines (trouver des groupes manquants)

cr0x@server:~$ lspci -tv
-+-[0000:00]-+-00.0  Intel Corporation Device 1234
 |           +-01.0-[01]----00.0  Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3
 |           +-1d.0-[3b]----00.0  NVIDIA Corporation Device 1eb8
 |           \-1f.6  Intel Corporation Ethernet Connection (7) I219-LM

Sens : Si un port racine attendu ou un dispositif en aval manque entièrement, vous n’avez pas affaire à un
problème de pilote. Vous avez affaire à l’énumération qui ne se produit pas.
Décision : Des branches entières manquantes après une intervention CPU/ventirad suggèrent fortement un reseat/une orientation du CPU ou des broches pliées affectant ce root complex PCIe.

Tâche 7 : Vérifier les erreurs NVMe qui sont en réalité des problèmes de lien

cr0x@server:~$ sudo dmesg | egrep -i 'nvme|pcie|AER|link down|corrected error' | tail -n 30
[   92.112233] pcieport 0000:00:1d.0: AER: Corrected error received: 0000:00:1d.0
[   92.112240] pcieport 0000:00:1d.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
[   92.112244] pcieport 0000:00:1d.0:   device [8086:1234] error status/mask=00000001/00002000
[   92.112250] pcieport 0000:3b:00.0: AER: Corrected error received: 0000:3b:00.0
[   92.112256] nvme nvme0: Abort status: 0x371

Sens : Des AER Physical Layer corrigés plus des aborts NVMe peuvent indiquer un lien PCIe marginal.
Cela peut être un câble/riser/périphérique, mais aussi des problèmes de contact du socket CPU sur le groupe de lanes.
Décision : Si les erreurs disparaissent après un reseat ou changent avec le couple du ventirad, arrêtez de blâmer le SSD.

Tâche 8 : Confirmer le mode ECC et les vitesses mémoire (chute causée par le BIOS)

cr0x@server:~$ sudo dmidecode -t memory | egrep -i 'Type:|Type Detail:|Error Correction Type:|Configured Memory Speed:' | head -n 20
	Error Correction Type: Multi-bit ECC
	Type: DDR4
	Type Detail: Synchronous Registered (Buffered)
	Configured Memory Speed: 2666 MT/s

Sens : Si la vitesse configurée est plus basse que prévu sur tous les DIMMs, le BIOS a peut-être basculé
en mode de repli à cause de problèmes d’entraînement. Parfois c’est le « mode sûr » après des boots ratés ; parfois c’est une marginalité réelle.
Décision : Si la vitesse chute après une intervention matérielle, considérez-la comme un canari : re-vérifiez le reseat et le socket, puis ré-entraînez la mémoire dans le BIOS si la plateforme le permet.

Tâche 9 : Vérifier le throttling CPU et les limites thermiques (les problèmes de pression de refroidisseur apparaissent ici)

cr0x@server:~$ sudo turbostat --Summary --quiet --interval 1 --num_iterations 3
Average:	CPU     Avg_MHz	Busy%	Bzy_MHz	TSC_MHz	PkgTmp	PkgWatt
Average:	all     2100	45.32	4632	2000	92	195.12

Sens : Une température de package élevée et des watts élevés avec une fréquence instable suggèrent des limites thermiques ou d’alimentation.
Un refroidisseur mal monté peut causer des points chauds et des instabilités étranges qui ressemblent à un « mauvais silicium ».
Décision : Si les températures sont élevées juste après une intervention, remontez le refroidisseur avec le couple correct et une application de pâte adéquate avant de toucher aux réglages firmware.

Tâche 10 : Test de charge pour reproduire de façon contrôlée (ne pas deviner)

cr0x@server:~$ stress-ng --cpu 32 --vm 4 --vm-bytes 75% --timeout 120s --metrics-brief
stress-ng: info:  [2417] dispatching hogs: 32 cpu, 4 vm
stress-ng: metrc: [2417] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: metrc: [2417] cpu             84512    120.02   3790.11     21.43      704.1
stress-ng: metrc: [2417] vm               9123    120.01    457.33    210.88       76.0
stress-ng: info:  [2417] successful run completed in 120.02s

Sens : Si ça ne plante qu’en pression CPU+mémoire combinée, suspectez des contacts marginaux, la VRM, ou
des problèmes thermiques plus que des « bugs de driver ».
Décision : Utilisez ceci pour reproduire après chaque changement (reseat, échange DIMM, réglage BIOS). Si la signature du crash change, vous affinez le diagnostic.

Tâche 11 : Chercher des rapports d’erreurs matérielles type WHEA sur Linux (tendance du compteur MCE)

cr0x@server:~$ sudo mcelog --client
hardware event: corrected memory error
status: 0x9c20400000010091
misc: 0x0
addr: 0x0000000123456780
mcgstatus: 0x0

Sens : Des erreurs corrigées répétées ne sont pas « normales ». Ce sont des avertissements précoces.
Décision : Si les erreurs corrigées augmentent après un reseat CPU/ventirad, vous avez probablement empiré la pression de contact ; revenez en arrière et réinstallez soigneusement.

Tâche 12 : Valider que le ralentissement du stockage n’est pas dû à l’entraînement du lien CPU

cr0x@server:~$ sudo nvme list
Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
/dev/nvme0n1     S5X0NX0R123456       ACME NVMe Gen4 SSD 3.84TB                1         3.84  TB /   3.84  TB    512   B +  0 B   3B2QEXM7

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep -i 'media_errors|num_err_log_entries|warning_temp_time'
media_errors                    : 0
num_err_log_entries             : 3
warning_temp_time               : 0

Sens : Des erreurs média propres mais quelques entrées de log plus des AER dans dmesg suggèrent une instabilité de couche liaison,
pas une mort de NAND.
Décision : Si le stockage « lent » corrèle avec un downtraining PCIe (Tâche 5), considérez le chemin socket/PCIe comme suspect principal avant de RMA les disques.

Tâche 13 : Confirmer la version BIOS/UEFI depuis l’OS (quand vous suspectez des régressions d’entraînement)

cr0x@server:~$ sudo dmidecode -t bios | egrep -i 'Vendor:|Version:|Release Date:'
Vendor: American Megatrends International, LLC.
Version: 2.6.1
Release Date: 08/14/2024

Sens : Les mises à jour BIOS peuvent changer le comportement d’entraînement mémoire et les défauts d’égalisation PCIe.
Décision : Si les symptômes apparaissent après une mise à jour BIOS, envisagez un rollback ou appliquez les réglages recommandés par le fournisseur ; mais ne laissez pas le firmware être le bouc émissaire d’un socket physiquement endommagé.

Tâche 14 : Détecter les interruptions/périphériques manquants qui pointent vers un root complex mort

cr0x@server:~$ cat /proc/interrupts | head -n 12
           CPU0       CPU1       CPU2       CPU3
  0:         22          0          0          0   IO-APIC   2-edge      timer
  1:          2          0          0          0   IO-APIC   1-edge      i8042
 24:     182993          0          0          0   PCI-MSI 524288-edge   eth0
 25:          0          0          0          0   PCI-MSI 1048576-edge  nvme0q0

Sens : Des lignes d’interruption bloquées à zéro pour un périphérique actif peuvent indiquer que le périphérique
n’est pas réellement actif, ou qu’il est bloqué à cause d’un problème de lien.
Décision : Combinez avec lspci et dmesg. Si le périphérique existe mais ne génère jamais d’interruptions sous charge, le chemin PCIe peut être instable (riser, slot ou groupe de lanes CPU).

Trois mini-récits d’entreprise issus du terrain

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

Une équipe a déployé un lot de nouveaux nœuds de calcul pour un service sensible à la latence. Le test d’acceptation
était simple : démarrer, rejoindre le cluster, exécuter une courte charge synthétique, expédier. Deux jours plus tard, un sous-ensemble
de nœuds a commencé à signaler des timeouts de stockage intermittents. Tout le monde s’est focalisé sur les disques NVMe, parce que les logs
regorgeaient d’erreurs d’E/S et l’outil santé du fournisseur restait étrangement silencieux.

La mauvaise hypothèse : « Les erreurs de stockage signifient que le stockage est cassé. » C’est une histoire confortable parce qu’elle limite
le rayon d’impact. On échange un disque, on passe à autre chose. Mais les échanges de disques n’ont rien changé. Les mêmes nœuds continuaient à flancher.

Un SRE a finalement regardé l’état d’entraînement PCIe à travers les nœuds et a remarqué un motif : les nœuds problématiques avaient
des liens en largeur et vitesse réduites, et les AER corrigés explosaient sous charge. Le service était correct au repos. Sous trafic, le tissu PCIe
devenait bruyant.

Le coupable était mécanique : ces nœuds avaient été retravaillés sur un établi où quelqu’un avait retiré le refroidisseur CPU pour « vérifier la pâte »
et l’avait réinstallé rapidement. La pression de montage était inégale, et la pression de contact LGA sur les broches liées au PCIe était marginale.
Un reseat CPU + couple appliqué correctement a réparé le tout. Aucune pièce remplacée.

La leçon est brutale : n’assumez pas que le sous-système qui tombe en panne est le composant cassé. Avec le LGA, un problème de contact de socket
peut se faire passer pour la moitié de votre inventaire matériel.

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

Une équipe plateforme voulait un retour plus rapide sur les réparations matérielles. Ils ont introduit un changement « d’efficacité » :
pré-appliquer des gabarits de pâte thermique et serrer les dissipateurs avec un tournevis électrique réglé sur un couple « sûr ».
La ligne de réparation est devenue plus rapide et plus cohérente — sur le papier.

En un mois, un filet de nœuds a commencé à montrer un motif spécifique : un canal mémoire manquant après reboot.
Les nœuds tournaient bien en configuration mémoire réduite, donc le problème a échappé aux vérifications initiales.
Finalement, des charges optimisées pour la bande passante mémoire ont commencé à rater leurs SLO.

L’enquête a trouvé deux problèmes. Premièrement, l’embrayage du tournevis électrique n’était pas calibré et variait avec l’état de la batterie.
Deuxièmement, les gabarits de pâte encourageaient une couche plus épaisse que l’idéal dans certains cas, ce qui changeait la distribution de la pression
après cycles thermiques. La pression de contact du socket LGA est devenue inégale, et une poignée de broches du canal mémoire affecté étaient à la limite.

La réparation a été douloureusement peu glamour : couple manuel avec un driver calibré, pâte appliquée selon une spécification poids/volume,
et une validation post-réparation vérifiant explicitement la présence et la vitesse des canaux mémoire. Le débit est revenu.

L’optimisation, c’est bien. L’optimisation non mesurée, c’est comme créer une nouvelle classe de « pannes matérielles fantômes ».

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

Une entreprise faisait tourner des charges mixtes sur une flotte incluant des nœuds vieillissants. Les pannes arrivaient, mais elles
étaient gérables parce que l’équipe pratiquait un rituel fastidieux : chaque action de service CPU avait une checklist documentée,
et chaque socket LGA retiré voyait son couvercle protecteur immédiatement remis. Aucune exception. Les gens se plaignaient.

Une semaine, un contractant est venu aider pour un rafraîchissement matériel. Il était compétent mais peu familier avec
l’« obsession du couvercle de socket » de l’équipe. En plein service, une carte est restée découverte sur un tapis antistatique pendant que
des pièces étaient triées. Quelqu’un a frotté la zone avec une manche. Rien de dramatique. Pas d’étincelles. Pas de bruits craquants.

La checklist l’a détecté. Le technicien qui remontait a inspecté le socket sous loupe avant de placer le CPU et a remarqué un léger
désalignement de broches. Parce que la règle du couvercle avait été suivie partout ailleurs, cette exception s’est distinguée. Ils ont mis la carte en quarantaine,
et le lot du contractant n’est pas allé en production.

La carte a été plus tard confirmée comme ayant un cluster de broches pliées qui aurait probablement produit une panne « boot mais RAM manquante ».
À la place, elle a produit un ticket ennuyeux et un remplacement contrôlé.

Deuxième blague courte (c’est tout ce que vous avez) : Le couvercle de socket est le petit chapeau en plastique qui empêche votre carte mère d’apprendre la danse interprétative avec une pince.

Erreurs courantes : symptôme → cause racine → correction

1) Seule la moitié de la RAM apparaît après maintenance

Symptôme : L’OS rapporte beaucoup moins de RAM ; dmidecode affiche « No Module Installed » pour tout un canal.

Cause racine : CPU pas assis à plat, couple du refroidisseur inégal, ou broches LGA pliées associées à ce canal.

Correction : Coupez l’alimentation, retirez le refroidisseur, inspectez le socket à la loupe et avec un éclairage oblique ; reseatez le CPU ; réappliquez la pâte ; serrez le refroidisseur en croix selon la spécification ; validez la présence du canal dans le BIOS et l’OS.

2) Le périphérique PCIe disparaît aléatoirement ou le lien s’entraîne vers le bas

Symptôme : lspci manque intermittemment un périphérique ; lspci -vv montre une largeur/vitesse rétrogradée ; AER dans dmesg.

Cause racine : contact de lane marginal (problème de broche socket), contamination riser/slot, ou flexion de la carte due au refroidisseur/retention.

Correction : Reseat le périphérique et le riser ; vérifiez l’état du lien ; si persistant sur un port racine, inspectez le socket CPU et remontez le refroidisseur avec le couple correct.

3) Redémarrages aléatoires seulement sous forte charge

Symptôme : Stable au repos, plante sous stress-ng ou charge réelle ; des MCE peuvent apparaître.

Cause racine : pression de contact marginale aggravée par l’expansion thermique ; instabilité VRM ou d’alimentation ; réglages BIOS agressifs.

Correction : Vérifiez les thermiques ; remontez le refroidisseur ; remettez le BIOS sur les défauts connus bons ; vérifiez MCE/EDAC ; si les erreurs corrèlent avec un canal, traitez le contact du socket comme prioritaire.

4) « Le CPU est mort » après un échange, mais l’ancien CPU fonctionne sur une autre carte

Symptôme : Le nouveau CPU ne fait pas POST dans une carte ; fonctionne ailleurs ; la carte échoue avec plusieurs CPU.

Cause racine : dommage du socket (broches LGA pliées), débris dans le socket, ou BIOS incompatible avec ce stepping CPU.

Correction : Inspectez le socket ; vérifiez la compatibilité BIOS ; ne clamppez pas à répétition des CPU dans un socket suspect — chaque cycle risque d’aggraver les dégâts.

5) Vitesse mémoire réduite sur toute la carte après une « maintenance mineure »

Symptôme : Vitesse mémoire configurée inférieure à la normale sur tous les DIMMs ; régression de performance.

Cause racine : BIOS en mode safe-mode après des erreurs, ou entraînement marginal dû à des problèmes de contact.

Correction : Corrigez d’abord l’assise physique ; puis effacez les échecs d’entraînement (selon la plateforme) ; re-validez avec dmidecode et des benchmarks de charge.

6) Vous redressez des broches PGA et ça marche… jusqu’à ce que ça ne marche plus

Symptôme : Le CPU réparé boot ; plus tard des fautes intermittentes apparaissent.

Cause racine : broches durcies par le travail ou micro-fissurées ; le contact est marginal électriquement sous cycles thermiques.

Correction : Considérez les CPU « redressés » comme temporaires. En production, remplacez-les ; ne les mettez pas dans des systèmes critiques.

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

Étape par étape : retrait et installation sécurisés du CPU (focus LGA)

1. Planifiez la validation : décidez à l’avance ce qu’un état « bon » signifie (taille RAM attendue, canaux, périphériques PCIe, vitesses de lien).
2. Coupez l’alimentation correctement : arrêt gracieux, puis retirez l’alimentation et attendez la décharge des rails de veille selon les recommandations de la plateforme.
3. Discipline ESD : bracelet de poignet, tapis mis à la terre, et éviter les vêtements synthétiques qui génèrent de l’électricité statique.
4. Retirez le refroidisseur uniformément : dévissez en croix pour éviter de tordre le CPU dans le socket.
5. Ouvrez le mécanisme du socket avec précaution : ne pas traîner le CPU sur les broches.
6. Installez le couvercle du socket immédiatement si le CPU est retiré : le couvercle n’est pas un emballage ; c’est une armure.
7. Inspectez : loupe, lumière oblique ; cherchez des rangées de broches qui ne reflètent pas la lumière de la même manière.
8. Nettoyez de façon appropriée : enlevez la poussière avec de l’air propre ; ne pas étaler d’huiles ; éviter les « solvants créatifs ».
9. Placez le CPU : alignez les encoches/marqueurs ; pas de force ; il doit s’enfoncer à plat.
10. Fermez la plaque de charge et le levier : attendez une résistance ; c’est la force de serrage, pas un combat.
11. Appliquez la pâte thermique de façon cohérente : suivez la spécification de la plateforme ; n’en mettez pas trop.
12. Serrez le refroidisseur selon la spécification : en croix ; couple calibré ; évitez les drivers électriques sauf s’ils sont validés.
13. Premier boot vers le firmware : confirmez les canaux mémoire, les vitesses et l’inventaire PCIe avant de démarrer l’OS.
14. Validation OS : lancez les tâches de diagnostic de la section correspondante et enregistrez les sorties pour le ticket.

Checklist de décision : quand blâmer le socket vs le CPU

• Blâmez le socket/la carte en premier quand : un canal ou un groupe de lanes est manquant, les symptômes changent avec le reseat/le couple, ou plusieurs CPU présentent le même problème sur la même carte.
• Blâmez le CPU en premier quand : le CPU échoue dans plusieurs cartes connues bonnes, ou vous voyez des erreurs internes CPU cohérentes non liées à une topologie de canal/port.
• Blâmez le firmware/config en premier quand : le comportement change après une mise à jour BIOS, des réglages ont été modifiés, ou des mismatches d’inventaire sont constants sans changements physiques.

Checklist d’hygiène opérationnelle (ce qu’il faut standardiser)

• Couvercles de socket stockés et utilisés, à chaque fois.
• Drivers de couple calibrés avec des réglages documentés par plateforme.
• Étape d’inspection de socket obligatoire pour tout comportement matériel « mystère » après une intervention.
• Script de validation post-maintenance vérifiant : lscpu, dmidecode emplacements mémoire, état des liens PCIe, et MCE/EDAC.
• Politique de quarantaine : toute carte suspectée de dommage aux broches LGA est étiquetée et retirée de la rotation.

FAQ

1) Le LGA est-il toujours meilleur que le PGA ?

Meilleur pour les comptes de broches élevés et la performance électrique haute vitesse, oui. Meilleur pour la manutention sur le terrain, non.
« Mieux » dépend si votre douleur provient de contraintes d’ingénierie ou de dommages induits par les techniciens.

2) Pourquoi ne pas garder les broches sur le CPU pour protéger la carte mère coûteuse ?

Parce que la partie coûteuse n’est pas seulement la carte ; c’est la capacité de la plateforme à supporter des E/S denses et rapides et la distribution d’alimentation.
Le LGA réduit la fragilité côté CPU et permet une densité de contact plus élevée avec de meilleures caractéristiques de signal. Le coût est un risque déplacé.

3) Des broches LGA pliées empêchent-elles toujours le démarrage ?

Non. C’est pourquoi elles sont dangereuses. Un petit ensemble de broches pliées peut retirer un canal mémoire ou dégrader le PCIe sans tuer le POST.
Vous obtenez un serveur « fonctionnel » qui sous-performe ou génère des erreurs sous charge.

4) Peut-on redresser des broches LGA ?

Parfois, physiquement. Opérationnellement, cela vaut rarement le coup en production.
Si vous essayez, vous avez besoin d’une bonne magnification, d’un éclairage et d’outils, et acceptez que vous puissiez transformer une carte récupérable en rebut.
Beaucoup d’organisations choisissent « remplacer la carte » parce que c’est traçable et reproductible.

5) Pourquoi la RAM manquante pointe souvent vers des problèmes de socket ?

Les canaux mémoire sont câblés via des groupes de contacts spécifiques. Si quelques contacts de ce groupe ne se connectent pas, le contrôleur mémoire
peut désactiver le canal lors de l’entraînement. L’OS rapporte alors moins de RAM, et dmidecode montre souvent des emplacements vides.

6) Quel est le rôle de la plaque de charge et du levier dans le LGA ?

Ils fournissent une force de serrage cohérente pour que chaque contact à ressort appuie contre son plot avec la bonne pression.
La cohérence est tout : trop peu donne des contacts intermittents ; trop fort peut fléchir la carte ou endommager le socket.

7) Pourquoi les liens PCIe s’entraînent-ils parfois à une vitesse inférieure après une intervention ?

L’égalisation et l’entraînement s’adaptent à la qualité du canal. Si la résistance de contact augmente ou si une lane devient marginale,
la plateforme peut négocier une vitesse plus basse ou une largeur réduite pour rester fiable. C’est une mesure défensive qui ressemble à une « régression de performance ».

8) Le PGA est-il réellement plus fiable ?

Pas intrinsèquement. Il est plus indulgent à la manipulation car la carte mère n’a pas de broches à ressort exposées.
Mais les broches CPU PGA sont plus faciles à plier lors de l’installation et peuvent fatiguer si elles sont redressées à plusieurs reprises.
La fiabilité vient des procédures, pas de la religion du socket.

9) Comment un problème de montage du refroidisseur peut-il causer des erreurs mémoire ?

Une pression inégale peut légèrement déformer la carte ou le boîtier CPU, modifiant la pression de contact à travers le champ LGA.
Les canaux mémoire sont sensibles ; un contact marginal peut devenir instable à chaud, provoquant des échecs d’entraînement ou des erreurs corrigées.

10) Quel test d’acceptation faire après un travail sur le CPU ?

Validez l’inventaire (CPU, emplacements RAM présents, périphériques PCIe attendus), vérifiez les vitesses/largeurs de lien, puis exécutez un court stress combiné CPU+mémoire.
Vérifiez aussi les logs pour MCE/EDAC et les AER PCIe corrigés. « Pas d’erreurs » vaut mieux que « on dirait que ça va ».

Prochaines étapes pratiques

Voici l’attitude opérationnelle qui vous tient à l’écart de l’enfer des sockets :
traitez les sockets LGA comme des composants de précision, pas « juste un connecteur ». Standardisez le couple, l’inspection,
et la validation post-maintenance. Ne laissez pas « ça boot » être votre définition de « sain ».

Une citation, parce qu’elle appartient à toute salle d’opérations : L’espoir n’est pas une stratégie. — idée paraphrasée, souvent attribuée à des leaders ingénierie et opérations.

1. Formalisez une procédure de service CPU incluant la discipline du couvercle de socket et l’inspection.
2. Automatisez les vérifications post-maintenance en utilisant les tâches ci-dessus (topologie CPU, inventaire DIMM, état lien PCIe, logs d’erreur).
3. Formez les personnes au mapping symptôme → cause : canal/lane manquant implique contact ou assise ; pannes sous charge impliquent marginalité.
4. Quarantainez immédiatement les cartes suspectes. Les reseats répétés d’un socket LGA endommagé sont la façon de transformer « peut-être récupérable » en « définitivement non récupérable ».
5. Arrêtez d’« optimiser » avec des outils non calibrés. Si vous utilisez des drivers électriques, validez le couple selon l’état de la batterie et les opérateurs, ou ne les utilisez pas.

L’industrie n’a pas déplacé les broches vers la carte mère pour embêter les techniciens. Elle l’a fait parce qu’elle avait besoin
de plus de connexions, d’un meilleur comportement électrique, et d’une mécanique prévisible à grande échelle. Votre travail en production
est de respecter ce compromis — et de diagnostiquer rapidement quand la réalité mord.