COMPTOIR
register

L'Hyper-Threading des puces Skylake et Kaby Lake les rendrait instables

Les développeurs de Debian viennent d'envoyer un courriel à tous les utilisateurs de leur système d'exploitation pour les prévenir d'un défaut pouvant altérer la stabilité de leurs machines. En effet, il leur a été remonté que les puces Skylake et Kaby Lake d'Intel (que ça soit dans leurs versions mobiles, desktop, HEDT ou serveur) souffrent un défaut processeur/microcode qui, lorsque déclenché, amènerait le système à un comportement imprévisible dont résulteraient corruption de données, plantage de logiciel ou carrément instabilité du système d'exploitation.

 

Ce défaut leur a tout d'abord été signalé par un développeur du projet OCaml dont le compilateur posait problème avec ces puces. Ces derniers avaient contacté Intel à ce sujet, sans réponse. Ils se sont cependant depuis rendu compte que les mises à jour du microcode des puces avaient corrigé le tir et ont cherché dans la documentation du géant bleu pour trouver ce qui faisait défaut. Voici d'ailleurs le nom donné à ces erreurs, ainsi que les erreurs qui leurs sont imputées et solutions apportées :

 

  • Errata: SKZ7/SKW144/SKL150/SKX150/SKZ7/KBL095/KBW095 Short Loops Which Use AH/BH/CH/DH Registers May Cause Unpredictable System Behavior.
  • Problem: Under complex micro-architectural conditions, short loops of less than 64 instructions that use AH, BH, CH or DH registers as well as their corresponding wider register (e.g. RAX, EAX or AX for AH) may cause unpredictable system behavior. This can only happen when both logical processors on the same physical processor are active.
  • Implication: Due to this erratum, the system may experience unpredictable system behavior.
  • Related processor signatures and microcode revisions:
  • Skylake : 0x406e3, 0x506e3 (fixed in revision 0xb9/0xba and later, public fix in linux microcode 20170511)
  • Skylake : 0x50654 (no information, erratum listed)
  • Kaby Lake : 0x806e9, 0x906e9 (defect still exists in revision 0x48, fix available as a BIOS/UEFI update)

 

Ce défaut spécifique ne toucherait donc que les applications utilisant des éléments posant problème dans le cadre ci-dessus (sous tous les systèmes, pas uniquement Debian ou autre sous noyau Linux), ce qui limite certainement la casse côté joueurs ou chez Tata Suzanne. Les développeurs devraient cependant y prêter attention et vérifier si une mise à jour n'a pas été mise en place pour leur système d'exploitation. Du côté de Debian, les versions 8 "Jessie" et 9 "Stretch" ont le droit à un correctif pour Skylake dans les dépôts non-free de Stretch et backports de Jessie. Pour les puces Kaby Lake, l'erreur semble toujours être là et nécessite une mise à jour du BIOS/UEFI. Si vous avez donc un doute sur la version de votre microcode ou celle de votre BIOS/UEFI, il est conseillé de désactiver l'Hyper-Threading dans le BIOS/UEFI et de faire ce qu'il faut pour corriger le tir au risque de bosser sur un système instable.

 

intel core x face

Un poil avant ?

Besoin de place ? Faites un backup de vos jeux Steam

Un peu plus tard ...

MSi a des mobales µATX A320 et B350 qui ne clignotent pas, les Pro-VD

Les 33 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Xorg, le Mercredi 28 Juin 2017 à 09h23  
Ouais enfin, comme je dis toujours, quand on utilise du code périmé, on peut s'en prendre qu'à soi-même...
Avoir son microcode à jour, ce n'est pas bien compliqué.
Désactiver l'HT sur un i7, il n'y a rien de plus triste, on se retrouve avec un i5 avec 2Mo de L3 de plus, je n'appelle pas ça une solution. Quand on achète un HT, c'est pour profiter de l'HT, aucun intérêt d'acheter un i7 si c'est pour désactiver l'HT.

Après, l'histoire de continuer ce troll, utiliser une Debian "stable" sur du hardware récent, c'est juste... Inqualifiable. Debian utilise généralement des paquets dont la version est ancienne, et donc des anciens logiciels qui ne supportent pas forcément du hardware récent.
par Un #ragoteur déconnecté de Lorraine, le Mardi 27 Juin 2017 à 16h32  
par L'Ours le Mardi 27 Juin 2017 à 05h16
J'allais hurler contre Intel, vu qu'il fournissent le compilateur C/C++ majoritairement utilisé, mais ça semble se passer avec gcc, celui qui est libre. A sur veiller.
Ce côté libre pourrait expliquer un bout de code problématique utilisé dans d'autres compilos

En tout cas c'est très bizarre qu'un tel problème (clairement lié à la hiérarchie mémoire) soit si ciblé, la piste de la randomisation (beurk) des adresses virtuelles pourrait pointer vers une mauvaise gestion de l'architecture elle-même par l'OS ou le code (tentative d'utilisation du L3 des 2 CCX) mais ça arriverait certainement dans des cas bien plus courants.
par LOracle, le Mardi 27 Juin 2017 à 11h18  
par Ragoti Ragota le Lundi 26 Juin 2017 à 16h24
Sauf si tu bosses sous debian etc, cela peut être vraiment problématique d'un point de vue productif, compilation et autre, mais bon les gens comme toi sous windaube sont à des années lumières de comprendre le problème
Fait tourner OCaml sous Windows et je suis à peu près certain que ça arrivera. Car le bug a été mis en évidence par les gens qui bossent sur (ou avec?) le langage OCaml.
par Un ragoteur macagneur d'Ile-de-France, le Mardi 27 Juin 2017 à 09h26  
par Un #ragoteur déconnecté de Lorraine le Lundi 26 Juin 2017 à 23h12
Pour Ryzen c'est quand même louche car apparemment ça n'arrive précisément que lors de compilation C... ça pourrait être lié au code des compilateurs eux-mêmes.
Absolument pas (cela arrive aussi avec llvm/clang, et toutes les versions de gcc): c'est juste que les compilateurs C/C++ sous Linux sont hyper-gourmands en ressources processeur (avec beaucoup d'opérations qui engendrent un très fort stress sur les caches, en particulier) et qui charge ce dernier (lors des compilations en parallèle, qui sont aujourd'hui la norme) à 100% sur tous les coeurs (et 'threads' SMT quand présents/activés).
C'est très différent d'un Prime95 qui engendrera très peut de mouvements de données entre caches, par exemple, même s'il charge aussi à 100% tous les coeurs.

Par ailleurs, d'autres charges sous d'autres OS sont aussi affectées par ce bogue. Il se trouve simplement que les compilateurs sont les plus affectés par lui (en particulier quand vous compilez de zéro un système Linux entier, comme avec Gentoo: des heures entières à compiler des logiciels de tous genres vont engendrer pratiquement toutes les combinaisons possibles et imaginables de séquences d'instructions du CPU: un excellent révélateur de bogue(s) pour ce dernier).
par UpsiloNIX, le Mardi 27 Juin 2017 à 07h36  
J'ai eu le mail hier, la MAJ du microcode a été poussée au niveau des fabricants de CM mais ceux-ci n'ont pas encore release de Bios avec.
Perso j'ai un Skylake depuis décembre et un Kaby depuis janvier et pas encore constaté de soucis, c'est pas faute de compiler des trucs sur l'un et jouer, encoder sur l'autre.
par Un champion du monde embusqué, le Mardi 27 Juin 2017 à 06h50  
par Un ragoteur macagneur d'Ile-de-France le Lundi 26 Juin 2017 à 15h21
A noter qu'il y a un problème du même genre avec Ryzen... Sauf que sur ce dernier, la cause reste pour l'instant inconnue et n'est donc pas corrigée par les derniers micro-codes...
C'est pas un problème de même genre, puisque la désactivation du SMT ne résout pas le problème. Et c'est un problème qui n'arrive que durant un compilation, pas durant un stress test. Personne n'a put reproduire le problème hors compilation.
Ca n'a donc rien à voir, et personne ne sait si c'est lié au CPU, ou à la carte mère, ou aux deux.
par L'Ours, le Mardi 27 Juin 2017 à 05h16  
par Un #ragoteur déconnecté de Lorraine le Lundi 26 Juin 2017 à 23h12
Pour Ryzen c'est quand même louche car apparemment ça n'arrive précisément que lors de compilation C... ça pourrait être lié au code des compilateurs eux-mêmes.
J'allais hurler contre Intel, vu qu'il fournissent le compilateur C/C++ majoritairement utilisé, mais ça semble se passer avec gcc, celui qui est libre. A sur veiller.
par Un #ragoteur déconnecté de Lorraine, le Lundi 26 Juin 2017 à 23h12  
par Un ragoteur macagneur d'Ile-de-France le Lundi 26 Juin 2017 à 20h41
Oui, tous les CPU ont des bogues, mais pour l'instant, Ryzen et KL sont sans solution par rapport à des bogues particulièrement handicapants.
Pour Ryzen c'est quand même louche car apparemment ça n'arrive précisément que lors de compilation C... ça pourrait être lié au code des compilateurs eux-mêmes.
par Un ragoteur macagneur d'Ile-de-France, le Lundi 26 Juin 2017 à 20h41  
par cerealkellogs du Nord-Pas-de-Calais le Lundi 26 Juin 2017 à 16h19
Non mais la new parle d'Intel est tu viens avec ton troll d'un mec qui a un probleme sur un forum
Me traiter de troll alors que je ne fais que pointer les faiblesses de tous les CPU modernes (moi, je m'en fout que ce soit Intel ou AMD), fait de *vous* le troll (et le malpoli) dans cette affaire.

Oui, tous les CPU ont des bogues, mais pour l'instant, Ryzen et KL sont sans solution par rapport à des bogues particulièrement handicapants.
par Un ragoteur qui aime les de Bourgogne, le Lundi 26 Juin 2017 à 19h19  
par cerealkellogs du Nord-Pas-de-Calais le Lundi 26 Juin 2017 à 16h19
Non mais la new parle d'Intel est tu viens avec ton troll d'un mec qui a un probleme sur un forum, tu veux que je t'en sorte combien de probleme avec l'hyper-threading et Intel sur google !?
Chaque nouveau proc a plus ou moins son lot de mésaventure gageons pour que cela soit corrigé dans un, moyen/long terme...
Cela ne semble pas un troll et il semble ne pas avoir qu'une seule personne ayant remonté l'info. Tout cela montre que tous les fabricants/concepteurs de puces un tant soit peu complexe font face à ce genre de soucis.
par mklmkl embusqué, le Lundi 26 Juin 2017 à 18h55  
par pascal2lille le Lundi 26 Juin 2017 à 17h13
Est-ce que le problème touche aussi les puces Broadwell-E qui utilisent le hyper threading ?
Non seulement les puces skylake
par Argetlame, le Lundi 26 Juin 2017 à 17h20  
par Cristallix le Lundi 26 Juin 2017 à 14h56
Deux ans pour trouver la cause précise, nuance. Il y a déjà surement eu des soucis avant mais va trouver la cause toi avec tous les facteurs possibles dans un OS !
Oui c'est vrai que dans un OS aussi conséquent il y a de quoi ronger... n'en déplaise aux facteurs !