Échecs de décompression d’Oodle dus à l’instabilité des processeurs Intel
(radgametools.com)- 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)
- Erreur typique :
- 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
- Exemple : erreur erronée
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
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
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
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é
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
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’à »
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
Cela me rappelle un vieux billet de Raymond Chen : https://devblogs.microsoft.com/oldnewthing/20050412-47/?p=35...
xor eax, eaxdonne un résultat erroné, cela aurait pu réduire le nombre de demandes de support difficiles à déboguerCette 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...
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
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
https://www.radgametools.com/granny.html
https://www.radgametools.com/iggy.htm
https://www.radgametools.com/milesperf.htm
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
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
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