1 points par GN⁺ 2024-02-25 | 1 commentaires | Partager sur WhatsApp
  • L’instabilité matérielle des processeurs Intel Core de 13e et 14e génération peut se manifester par des échecs de décompression Oodle Data et des crashes dans les jeux basés sur Unreal Engine
  • L’erreur représentative est DecompressShader(): Could not decompress shader (GetShaderCompressionFormat=Oodle), et le problème est lié non pas à Oodle lui-même mais plus généralement aux charges de travail multithread qui sollicitent fortement le CPU
  • Des crashes peuvent aussi apparaître dans Adobe Premiere, RealBench, CineBench, Prime95, Handbrake, Visual Studio, etc., et comme la cause est le CPU, cela peut malgré tout ressembler à une erreur GPU comme out of video memory
  • Intel a identifié comme cause l’usure rapide du circuit interne de signal d’horloge de la puce, provoquée par la combinaison de plusieurs problèmes, et les composants déjà physiquement dégradés doivent être remplacés
  • Au 1er octobre 2024, des mises à jour BIOS évitant les conditions de fonctionnement à l’origine des dommages ont commencé à être déployées, et elles doivent être installées avant l’apparition des symptômes

Instabilité du CPU révélée par des crashes de jeux

  • Un problème matériel affectant les processeurs Intel Core de 13e et 14e génération des séries 13xxx et 14xxx peut entraîner une instabilité générale du système
  • Dans les jeux basés sur Unreal Engine, cela peut provoquer des échecs de décompression Oodle Data et des crashes
    • Erreur typique : DecompressShader(): Could not decompress shader (GetShaderCompressionFormat=Oodle)
  • Ce phénomène ne se limite pas à Oodle
    • Les programmes qui sollicitent fortement le processeur sur plusieurs threads peuvent eux aussi provoquer des crashes ou des comportements imprévisibles
    • Des crashes ont également été observés avec Adobe Premiere, RealBench, CineBench, Prime95, Handbrake et Visual Studio
  • Bien que le CPU soit en cause, certains messages peuvent faire croire à un problème GPU
    • Exemple : erreur erronée out of video memory

Cause et mesures à prendre

  • Intel a confirmé que la cause profonde est l’usure rapide du circuit interne de signal d’horloge de la puce
    • La dégradation du circuit résulte de la combinaison de plusieurs problèmes
    • Il s’agit d’une usure physique de la puce elle-même, irréversible une fois amorcée
  • Les composants déjà dégradés doivent être remplacés
    • La procédure de remplacement est résumée dans ce guide
  • Au 1er octobre 2024, de nouvelles mises à jour BIOS visant à éviter les conditions de fonctionnement qui endommagent le circuit ont commencé à être diffusées
    • Pour les PC portables ou de bureau préassemblés, le fabricant déploie déjà ou déploiera bientôt une mise à jour BIOS intégrant ce contournement
    • Pour les PC assemblés soi-même, il faut vérifier sur le site du fabricant de la carte mère si une image BIOS mise à jour est disponible
  • Il faut installer la mise à jour BIOS avant l’apparition des symptômes
    • Une fois les crashes commencés, il est trop tard pour corriger le problème par logiciel

1 commentaires

 
GN⁺ 2024-02-25
Avis sur Hacker News
  • Ça me rappelle un incident que j’ai connu lors de l’adoption initiale de l’AMD Threadripper 3970X : https://forum.level1techs.com/t/amd-threadripper-3970x-under...
    Discussion HN : https://news.ycombinator.com/item?id=22382946
    Au final, nous avons enquêté sur le problème avec AMD pendant plusieurs mois, et AMD nous a largement indemnisés pour les allers-retours pénibles de carte mère et de CPU, mais depuis, nous continuons à l’utiliser avec une image BIOS personnalisée fournie par AMD. Il semble qu’au bout du compte, c’était un problème côté Gigabyte

  • J’ai reçu un 13900K défectueux et je peux confirmer qu’au moins dans mon cas, le problème apparaissait même avec les réglages PL1/PL2 par défaut
    Je faisais tourner de l’apprentissage par renforcement sur ce système, qui plantait sans arrêt, et j’ai mis pas mal de temps à en trouver la cause ; en remplaçant le CPU par un 13700KF utilisé dans un autre PC, le problème a disparu
    Quand j’ai demandé un RMA à Intel, on m’a répondu que ma carte mère MSI ne prenait pas Linux en charge ; après avoir envoyé le dépôt GitHub officiel d’Intel contenant le microcode qui active cette prise en charge, mon interlocuteur a changé. À ce moment-là, il m’a semblé évident qu’Intel essayait d’éviter le RMA autant que possible, et heureusement, vivant en Europe, j’ai pu le faire avancer via l’organisme local de protection des consommateurs
    Entre-temps, j’ai vu chez un vendeur en ligne une promotion groupée sur un 7950X et une carte mère, je l’ai achetée, puis j’ai revendu mon ancienne carte mère et le 13900K reçu en RMA d’occasion. J’utilisais Intel parce qu’Intel sponsorisait certains projets de data science, mais je ne compte plus jamais racheter Intel

    • Mon 7700K aussi est resté instable dès l’achat, et 16 mois de mises à jour du BIOS n’ont pas résolu le problème. Il se peut que les processeurs de dernière génération rencontrent davantage de problèmes que les conceptions plus simples d’autrefois
  • Pour réduire les problèmes de sécurité, il faut désactiver l’hyperthreading, et maintenant, pour réduire les problèmes de corruption mémoire, il semble qu’il faille aussi désactiver le mode turbo
    À force de désactiver les états C pour éviter les attaques par canal auxiliaire, puis les cœurs efficaces pour éviter les problèmes de planificateur, on finit à un moment par revenir à un ensemble de fonctionnalités d’il y a 20 ans :P

    • Le problème semble venir des différences de firmware entre plusieurs fabricants de cartes mères. J’utilise une carte mère avec un Ryzen 7950X, et elle refusait de démarrer de façon aléatoire ; il fallait retirer la pile pour la réinitialiser complètement avant qu’elle refonctionne. Au final, une mise à jour du firmware a corrigé ce bug
    • Il suffit de désactiver l’overclocking
    • À l’époque, on savait fabriquer du matériel fiable, plutôt que d’entasser des fonctions pas assez validées et de viser des chiffres de pointe avec des compromis douteux
    • Honnêtement, le monde aurait peut-être été meilleur si l’on s’était arrêté aux Coppermine ou Tualatin et qu’on s’était concentré uniquement sur l’amélioration logicielle
    • Bon, rapide, pas cher. Il faut en choisir deux sur les trois
  • J’ai récemment monté une nouvelle machine avec un i9 149KF et une carte mère Asus Formula. L’objectif était d’en faire un système VFIO pour faire tourner Windows et jouer
    La rendre stable a été un cauchemar, et aucun des réglages par défaut de la carte mère n’était correct. Les jeux plantaient, et la compilation du noyau comme celle d’Emacs échouaient
    Au final, j’ai dû limiter le turbo de la puce 6 GHz à 5,4 GHz, et activer des réglages limitant la puissance maximale et la température de throttling à 90 °C
    Maintenant, le système semble stable, et je peux jouer en 4K à 120 fps tout en maintenant 5,4 GHz sans throttling. Cela dit, ça me dérange de ne pouvoir, avec aucun réglage, l’utiliser aux chiffres publicitaires pour lesquels j’ai payé

    • Le fait d’avoir limité la température de throttling à 90 °C signifie-t-il qu’avant, elle dépassait 90 °C ?
      Au début, je trouvais ça absurde, mais d’après Intel, c’est apparemment normal pour cette puce : « Le processeur prend en charge jusqu’à 100 °C, et les températures inférieures à ce seuil sont normales et dans la plage attendue »
      https://community.intel.com/t5/Processors/i9-14900K-temperat...
      Ça reste vraiment bizarre. D’un côté, on devrait évidemment obtenir les performances annoncées et payées, mais de l’autre, faire tourner un CPU à 90–100 °C semble délirant. J’ai l’impression qu’Intel est vraiment acculé. Je suis curieux de savoir quelle configuration de refroidissement tu utilises
    • Je n’aime pas le marketing du Turbo Boost
      C’est comme quand les FAI vendaient autrefois du « jusqu’à X Mbps ». Cette puce aussi est annoncée comme pouvant monter en Turbo Boost « jusqu’à 6,00 GHz »
      En pratique, c’est de l’overclocking automatique, et comme tu l’as constaté, parfois elle ne peut même pas tenir cette fréquence de façon stable. Certaines puces ne fonctionneront jamais à « jusqu’à 6,00 GHz », mais ce n’est pas un mensonge. Puisque c’est « jusqu’à »
    • J’ai récemment monté un système avec une 14900KF, une carte mère ASUS TUF et un refroidisseur NZXT Kraken 360, et pour l’instant je n’ai pas eu de problème avec les réglages BIOS par défaut. Par défaut, c’était 5,7 GHz, et je n’ai jamais vu la température dépasser 70 °C
      Cela dit, je n’ai pas non plus vu la charge CPU dépasser 40 %, et je n’ai pas lancé de logiciel de benchmark. 5,4 GHz à 90 °C, c’est très différent de ce que je vois sur mon processeur, donc je suis curieux de savoir quel refroidissement tu utilises. Même avec une fréquence plus élevée, il se peut aussi que je n’aie pas poussé mon CPU aussi fort
    • Je me demande si tu as tout nettoyé soigneusement et remonté le refroidisseur avec de la pâte thermique neuve. J’ai déjà vu un comportement similaire quand la pâte avait été mal appliquée et avait formé des bulles d’air. Les températures affichées par cœur sont-elles très différentes ?
    • C’est inquiétant de voir qu’un écart de fréquence de 10 % peut faire basculer la stabilité. Quelle marge reste-t-il réellement ?
  • Cela me rappelle un vieux billet de Raymond Chen : https://devblogs.microsoft.com/oldnewthing/20050412-47/?p=35...

    • Je me demande pourquoi ils n’ont pas intégré à l’analyseur de crash système un composant qui indique à l’utilisateur que le CPU se comporte anormalement. Par exemple, s’il pouvait signaler que même une instruction de base comme xor eax, eax donne un résultat erroné, cela aurait pu réduire le nombre de demandes de support difficiles à déboguer
  • Cette situation me paraît familière. Elle me rappelle l’ancien Pentium III 1,13 GHz
    https://www.tomshardware.com/reviews/intel-admits-problems-p...

    • Indépendamment du sujet principal, il faut saluer le fait que Tom’s Hardware serve encore parfaitement une page web publiée il y a 24 ans
  • On rencontre régulièrement des problèmes matériels aussi avec Zstd. Souvent, le décompresseur devient le premier composant à interagir avec des données arrivées par le réseau
    Comme dans ce cas, les décompresseurs sont très sensibles aux bits retournés, avec ou sans checksum, et détectent donc souvent les problèmes matériels plus tôt que les autres processus tournant sur le même hôte
    Zstd a choisi de n’inclure qu’un checksum des données d’origine, ce qui suffit à garantir l’intégrité des données. Mais cela ne permet pas de vérifier si les données compressées ont été corrompues, ce qui rend plus difficile d’exclure le décompresseur comme cause de la corruption

    • Les données compressées, c’est comme les sauvegardes : elles ne sont pas valides tant qu’on ne les a pas vérifiées
  • Cette page ne semble pas être liée depuis d’autres pages publiques, donc on dirait une page créée pour répondre aux plaintes non sollicitées d’utilisateurs qui essayaient de remonter la piste de « oodle » dans leurs journaux d’erreurs. Un peu comme avec SQLite en 2006 [1]
    [1] https://news.ycombinator.com/item?id=36302805

  • Rien de surprenant
    À l’époque, j’avais acheté une carte ASUS TUF pour un 4790K parce que je voulais quelque chose de basique et que l’overclocking ou les réglages fins ne m’intéressaient pas. Mais le BIOS avait une autre idée
    Rien que pour éviter l’overclocking, il fallait régler manuellement une foule de paramètres, définir les timings de la RAM et passer en revue chaque option du BIOS pour vérifier qu’il n’overclockait pas d’une manière ou d’une autre. Les réglages « optimal » activaient des changements agressifs, comme la modification du multiplicateur de vitesse du bus

    • Comme d’autres l’ont dit, ce CPU « suffisamment basique » visait en fait directement le marché de l’overclocking, et la carte mère mentionnée était probablement du même genre. Ce n’est pas du tout une configuration de base, mais un système destiné aux réglages avancés. Simplement, c’est un système de réglage avancé vieux de 10 ans
    • Rares sont les gens qui achètent un processeur K sans s’intéresser à l’overclocking et aux réglages. Il n’est pas étonnant que le BIOS d’une carte mère gaming définisse ses valeurs « optimal » par défaut en partant de ce principe. Le marché gaming tourne autour des benchmarks
  • J’ai vécu quelque chose de similaire avec une carte mère Asus. Le tuning automatique la rendait instable et faisait planter le compilateur ; pour l’utiliser normalement, il fallait configurer le BIOS à la main
    Je pense que le problème est aggravé par la manière dont le SuperIO contrôle le refroidissement, car les crashs étaient liés à des pics de température à 100 °C. Les ventilateurs montent trop lentement et redescendent trop vite
    Sous Linux, on peut régler cela depuis l’espace utilisateur. Mais en réalité, ce n’est pas un indicateur retardé comme la température qui devrait piloter la phase de montée, mais un indicateur avancé comme le régulateur de tension. Ou bien le contrôleur p-state de Linux pourrait prédire le niveau de puissance et définir une vitesse de ventilateur plus élevée

    • Je suis justement en train de rencontrer ce problème. Ma configuration est Asus ROG Z790, 14900K, Noctua NH-D15
      La courbe de ventilation par défaut est inefficace, et ses oscillations constantes sont agaçantes. La température d’un seul P-core fait sans arrêt des pics, et les ventilateurs réagissent de façon erratique
      J’ai lu qu’augmenter le temps de montée rendait le comportement des ventilateurs plus fluide, mais d’après l’expérience ci-dessus, cela pourrait aussi provoquer une défaillance du processeur