Le noyau Linux détermine la nature de votre processeur AMD en lisant un numéro de famille et un numéro de modèle, puis en les cherchant dans une table. Si la table est fausse, tout ce qui en dépend devient discrètement faux aussi : contournements d'errata, gestion de l'énergie, compteurs de performance. Un patch intégré pour Linux 7.2-rc6 corrige exactement ce type d'erreur. Un changement antérieur avait donné toute la plage de modèles 0xd0 à 0xef de la famille 1Ah à Zen 6, alors que 0xd0 à 0xd7 est réservée à Zen 5. La correction découpe correctement la plage, et elle arrive avant que 7.2 ne devienne un noyau stable que les distributions transportent des années.
The short answer
Un patch intégré avant Linux 7.2-rc6 corrige les plages de modèles des processeurs AMD. Un changement du trente mai avait étendu Zen 6 aux modèles 0xc0 à 0xef de la famille 1Ah, alors que 0xd0 à 0xd7 est réservée à Zen 5. Le correctif, commit 52075128273ace53e6254e37899a47d40d4baf45, rend ce bloc et laisse à Zen 6 les plages 0x50 à 0x5f, 0x80 à 0xaf, 0xc0 à 0xcf et 0xd8 à 0xef. Aucun processeur commercialisé n'était concerné, ces plages étant des réservations pour des puces à venir. Le même lot de correctifs x86 réglait aussi un problème de memcmp() touchant les invités Xen.
Il existe une catégorie de bug noyau qui n'apparaît jamais dans un rapport, parce que le matériel qu'elle affecterait n'existe pas encore. Il attend dans une table, d'apparence correcte, que du silicium arrive pour le contredire. La confusion de plages de modèles AMD corrigée pour Linux 7.2-rc6 appartient à cette catégorie, et l'intéressant n'est pas le bug. C'est ce que le noyau fait de ces numéros.
Huit numéros de modèle, restitués
Zen 5 et Zen 6 partagent la famille 1Ah, 26 en décimal, et ne se distinguent que par le numéro de modèle. Le trente mai 2026, un patch de Pratik Vishwakarma, chez AMD, avait élargi la plage de détection de Zen 6, portant le dernier bloc de 0xc0 à 0xcf jusqu'à 0xef d'un seul geste. Ce genre d'extension est banal, AMD réservant de l'espace de modèles à l'avance pour que les nouvelles puces Ryzen et EPYC soient reconnues par des noyaux qui leur sont antérieurs.
L'extension a pris trop large. Les modèles 0xd0 à 0xd7 appartiennent à Zen 5, et le patch correctif intégré pour 7.2-rc6 découpe la plage en conséquence. Zen 6 garde 0xc0 à 0xcf et 0xd8 à 0xef, en plus des plages 0x50 à 0x5f et 0x80 à 0xaf qu'elle avait déjà. Zen 5 récupère ses huit modèles. Le commit est 52075128273ace53e6254e37899a47d40d4baf45.
Aucun poste de travail n'a été touché, et il vaut mieux le dire clairement que de présenter l'épisode comme un désastre évité de justesse. Ce sont des réservations. Ce qui rend le calendrier important, c'est que Linux 7.2 est presque là, et qu'un noyau stable n'est pas une chose que l'on corrige une fois. C'est une chose qui part dans les distributions d'entreprise et qui vit des années, si bien qu'une entrée fausse traîne derrière elle une longue file de rétroportages, de noyaux constructeurs et de rapports de bug confus.
Pourquoi une recherche dans une table mérite tant de soin
Si le noyau tient à connaître la génération d'une puce, c'est que la correspondance famille et modèle conditionne des comportements réels.
L'usage le plus lourd de conséquences concerne les errata. Les errata de processeur sont propres à un modèle, et leurs contournements s'appliquent par correspondance de famille, de modèle et de révision. Une puce classée dans la mauvaise génération peut hériter d'un contournement écrit pour un autre silicium, ou manquer celui qui la concerne. C'est le cas où la correction est réellement en jeu, et c'est pourquoi ces tables sont relues avec attention plutôt que validées d'office.
Le reste relève de la performance et de l'observabilité. Le pilote amd_pstate se comporte différemment selon la génération, et ce conditionnement a joué dans plusieurs changements récents d'ordonnancement et de fréquence turbo. La supervision des performances associe les événements par microarchitecture, donc une mauvaise génération donne des compteurs qui n'existent pas ou qui signifient autre chose. EDAC attache le support du contrôleur mémoire par modèle. Les chemins thermiques et énergétiques opèrent des contrôles comparables.
Rien de tout cela ne provoque en général de plantage. Cela produit une machine qui démarre, qui tourne, et qui se trouve discrètement à quelques pour cent de sa cible, ou qui remonte des valeurs ne correspondant pas à l'étiquette du tableau de bord. Ce sont les pannes coûteuses, parce que personne n'ouvre de ticket pour elles.
Vérifier vos propres machines
Les valeurs se lisent facilement et méritent d'être lues sur tout matériel récemment déployé. lscpu affiche ensemble CPU family, Model et Model name, et les mêmes nombres figurent dans /proc/cpuinfo sous cpu family et model. Le piège classique est la base : la famille 26 de lscpu est le 1Ah que vous voyez dans les patchs et les documents d'errata, et le modèle est affiché en décimal alors qu'AMD et les commits noyau parlent en hexadécimal. printf '%x\n' 208 renvoie d0 et tranche la question.
Le signal à guetter sur du matériel neuf n'est pas un numéro faux, c'est un numéro vague. Une chaîne Model name générique, ou une famille et un modèle pour lesquels votre noyau n'a manifestement pas d'entrée, indique que le noyau en cours est plus ancien que le silicium. Tout ce qui dépend de la génération tourne alors sur des valeurs par défaut plutôt que sur une connaissance de votre puce, ce qui est le plus souvent acceptable et parfois non.
Pour qui suit 7.2, ce correctif est arrivé avec un lot de corrections x86 qui comprenait aussi un correctif memcmp() affectant les machines virtuelles Xen, et rc6 était attendue une douzaine d'heures après le signalement du deux août. Au rythme habituel, cela place la version stable 7.2 dans quelques semaines.
Sources et pour aller plus loin
- Phoronix : Linux 7.2-rc6 corrige des processeurs AMD Zen 5 identifiés à tort comme Zen 6
- Phoronix : AMD élargit la plage de processeurs Zen 6 détectés par le noyau Linux
- Wccftech : AMD élargit le support de la famille Zen 6 dans Linux
- Documentation du noyau : le pilote amd_pstate
- Page de manuel de lscpu
Questions fréquentes
Ce bug a t il cassé quelque chose sur des machines réelles ?
Presque certainement pas, et autant le dire franchement. Les plages concernées sont des réservations pour du silicium qui n'est pas encore commercialisé, ce qui explique que l'erreur ait survécu de fin mai à début août sans que personne ne bute dessus. AMD publie ses plages de modèles avant le lancement pour que le noyau reconnaisse les nouvelles puces dès le premier jour plutôt que six mois plus tard, et ce provisionnement anticipé est justement l'endroit où une erreur de quelques quartets coûte le moins cher à commettre comme à corriger. Ce qui compte ici, c'est le calendrier plutôt que l'étendue des dégâts : Linux 7.2 est proche de la sortie, les distributions le transporteront longtemps, et une table de modèles fausse figée dans un noyau à longue durée de vie devient un problème de support qui survit au patch fautif.
Quelles sont les plages corrigées ?
Les deux architectures vivent dans la famille 1Ah, soit 26 en décimal. Après le correctif, Zen 5 possède les modèles 0xd0 à 0xd7 dans le bloc disputé, et Zen 6 conserve 0xc0 à 0xcf plus 0xd8 à 0xef, aux côtés de ses plages existantes 0x50 à 0x5f et 0x80 à 0xaf. Le changement revient sur une partie d'un patch du trente mai 2026, soumis par Pratik Vishwakarma d'AMD, qui avait étendu le bloc Zen 6 de 0xc0 à 0xcf jusqu'à 0xef d'un seul coup. Le commit correctif est 52075128273ace53e6254e37899a47d40d4baf45.
Qu'est ce qui dépend réellement de la génération Zen reconnue par le noyau ?
Bien plus de choses qu'on ne l'imagine. Le code x86 utilise la correspondance famille et modèle pour décider quels contournements d'errata appliquer, et c'est la partie qui a de vraies conséquences de correction. Au delà, le pilote amd_pstate adapte son comportement à la génération, le code de supervision des performances associe les événements différemment selon la microarchitecture, EDAC attache le support du contrôleur mémoire par modèle, et les chemins de remontée thermique et énergétique font des vérifications similaires. Une génération mal étiquetée ne produit généralement pas de plantage. Elle produit une machine qui fonctionne, et qui fonctionne légèrement de travers, d'une manière pénible à attribuer après coup.
Comment vérifier ce que mon noyau pense de mon processeur ?
Lancez lscpu et lisez ensemble les champs CPU family, Model et Model name. La famille 26 s'écrit 1Ah en hexadécimal, et le numéro de modèle est affiché en décimal, il faut donc le convertir avant de le comparer aux plages publiées en hexa : printf '%x\n' 208 donne d0. Les mêmes valeurs figurent dans /proc/cpuinfo sous cpu family et model. Pour une vue brute, l'utilitaire cpuid présent dans la plupart des dépôts affiche les feuilles directement. La bonne habitude sur toute nouvelle plateforme consiste à vérifier que la chaîne Model name est renseignée et précise, car une chaîne générique est souvent le premier signe que le noyau en cours est plus ancien que le silicium.
Était ce le seul correctif x86 de ce lot ?
Non. Le même ensemble de correctifs x86 destiné à 7.2-rc6 portait aussi une correction de l'implémentation de memcmp() qui affectait les machines virtuelles Xen. Les dernières versions candidates sont généralement faites de ce matériau exactement : de petites corrections circonscrites sur des points qu'il coûterait cher de découvrir après la sortie. Linux 7.2-rc6 devait sortir dans les douze heures environ après le signalement du deux août, ce qui place la version stable 7.2 à quelques semaines au rythme habituel.