Fallas de descompresión de 'Oodle' causadas por la inestabilidad de procesadores Intel

 (radgametools.com)
1 puntos por GN⁺ 2024-02-25 | 1 comentarios | Compartir por WhatsApp
  • La inestabilidad de hardware de los procesadores Intel Core de 13.ª y 14.ª generación puede manifestarse en juegos basados en Unreal Engine como fallas al descomprimir datos de Oodle y crashes
  • El error más representativo es DecompressShader(): Could not decompress shader (GetShaderCompressionFormat=Oodle), y el problema está relacionado no tanto con Oodle en sí, sino con tareas multihilo intensivas en CPU en general
  • También pueden aparecer crashes en Adobe Premiere, RealBench, CineBench, Prime95, Handbrake, Visual Studio, entre otros, y aunque la causa sea la CPU, puede parecer un error de GPU con mensajes como out of video memory
  • Intel confirmó que la causa es el envejecimiento acelerado del circuito interno de señal de reloj del chip debido a la superposición de varios problemas, y los componentes que ya se degradaron físicamente deben reemplazarse
  • Al 1 de octubre de 2024, comenzaron a distribuirse actualizaciones de BIOS para evitar las condiciones de operación que provocan el daño, por lo que deben instalarse antes de que aparezcan los síntomas

Inestabilidad de CPU que se manifiesta como crashes en juegos

  • Un problema de hardware en los procesadores Intel Core de 13.ª y 14.ª generación de las series 13xxx y 14xxx puede derivar en inestabilidad general del sistema
  • En juegos basados en Unreal Engine pueden producirse fallas de descompresión de datos de Oodle y crashes
    • Error representativo: DecompressShader(): Could not decompress shader (GetShaderCompressionFormat=Oodle)
  • Este fenómeno no se limita solo a Oodle
    • Los programas que usan fuertemente el procesador en varios hilos también pueden presentar crashes o comportamientos impredecibles
    • Se han observado crashes en Adobe Premiere, RealBench, CineBench, Prime95, Handbrake y Visual Studio, entre otros
  • Aunque la causa sea la CPU, pueden aparecer mensajes que parecen indicar un problema de GPU
    • Ejemplo: error incorrecto out of video memory

Causa y medidas necesarias

  • Intel identificó la causa raíz como el envejecimiento acelerado del circuito interno de señal de reloj del chip
    • La combinación de varios problemas provoca daños en el circuito
    • El daño es desgaste físico del propio chip y, una vez que avanza, no se puede revertir
  • Los componentes que ya presenten degradación deben reemplazarse
    • El procedimiento de reemplazo está resumido en esta guía
  • Al 1 de octubre de 2024, comenzaron a distribuirse nuevas actualizaciones de BIOS que evitan las condiciones de operación que causan el daño en el circuito
    • En laptops y PCs de escritorio preensambladas, los fabricantes ya están distribuyendo o distribuirán pronto actualizaciones de BIOS que incluyen esta mitigación
    • En PCs armadas por el usuario, hay que revisar en el sitio web del fabricante de la motherboard si ya está disponible la imagen de BIOS actualizada
  • La actualización de BIOS debe instalarse antes de que aparezcan los síntomas
    • Una vez que los crashes comienzan, ya es tarde para resolverlo por software

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-02-25
Comentarios en Hacker News

  • Me recuerda a lo que viví cuando adopté temprano un AMD Threadripper 3970X: https://forum.level1techs.com/t/amd-threadripper-3970x-under...
    Debate en HN: https://news.ycombinator.com/item?id=22382946
    Al final investigué el problema junto con AMD durante varios meses, y aunque AMD me compensó generosamente por la molestia de estar intercambiando la motherboard y el CPU, desde entonces sigo usándolo con una imagen de BIOS personalizada que me dieron. Al final, parece que fue un problema del lado de Gigabyte

  • Me tocó un 13900K defectuoso y, al menos en mi caso, puedo confirmar que el problema aparecía incluso con la configuración predeterminada de PL1/PL2
    Corría aprendizaje por refuerzo en ese sistema y se caía todo el tiempo, así que tardé bastante en encontrar la causa; al cambiar el CPU por un 13700KF que usaba en otra PC, el problema se resolvió
    Le pedí un RMA a Intel y me dijeron que la motherboard MSI que usaba no soportaba Linux; cuando les mandé el repositorio oficial de GitHub de Intel con el microcódigo para habilitar soporte, me cambiaron de agente. En ese momento quedó bastante claro que Intel estaba tratando de evitar el RMA al máximo, y por suerte vivo en Europa, así que tramité el RMA mediante la agencia regional de protección al consumidor
    Mientras tanto, vi una oferta en línea de un combo 7950X con motherboard y lo compré; luego vendí usada mi motherboard anterior junto con el 13900K que me llegó por RMA. Estaba usando Intel porque patrocinaba algunos proyectos de ciencia de datos, pero no pienso volver a comprar Intel

    • Mi 7700K también fue inestable desde después de comprarlo, y 16 meses de actualizaciones de BIOS no lo arreglaron. Puede que los procesadores de las generaciones más nuevas estén teniendo más problemas que los diseños más simples de antes

  • Para reducir los problemas de seguridad, parece que hay que desactivar el hyper-threading, y ahora para reducir los problemas de corrupción de memoria también hay que desactivar el modo turbo
    Si además desactivas los estados C para evitar ataques por canal lateral, y apagas los núcleos de eficiencia para esquivar problemas del scheduler, en algún momento terminas de vuelta con la lista de funciones de hace 20 años :P

    • Parece que el problema viene de las diferencias de firmware entre varios fabricantes de motherboards. Uso una motherboard con Ryzen 7950X que a veces no arrancaba al azar, y solo volvía a funcionar después de quitar la batería para resetearla por completo. Al final una actualización de firmware corrigió ese bug
    • Solo hay que desactivar el overclock
    • En esa época sabían cómo hacer hardware confiable, en lugar de meter funciones poco probadas y hacer concesiones dudosas para alcanzar cifras de vanguardia
    • Sinceramente, quizá el mundo habría sido mejor si nos hubiéramos quedado en Coppermine o Tualatin y solo nos hubiéramos enfocado en mejorar el software
    • Bueno, rápido y barato. Solo puedes elegir dos de las tres

  • Hace poco armé un sistema nuevo con un i9 149KF y una motherboard Asus Formula. La idea era correr Windows en un sistema VFIO y también jugar
    Hacer que funcionara de forma estable fue una pesadilla, y ni una sola de las configuraciones predeterminadas de la motherboard estaba bien. Los juegos se cerraban, y también fallaban las compilaciones del kernel y de Emacs
    Al final tuve que limitar el turbo del chip de 6GHz a 5.4GHz y activar una configuración que limita la potencia máxima y la temperatura de throttling a 90°C
    Ahora parece estable, y puedo sostener 5.4GHz sin throttling mientras juego a 120fps en 4K. Aun así, me deja incómodo saber que no puedo hacerlo funcionar bajo ninguna configuración con las cifras publicitadas por las que pagué

    • ¿Limitar la temperatura de throttling a 90°C significa que antes pasaba de 90°C?
      Al principio me pareció absurdo, pero según Intel eso es normal en este chip: “El procesador soporta hasta 100°C, y cualquier temperatura inferior a eso es normal y está dentro del rango esperado”
      https://community.intel.com/t5/Processors/i9-14900K-temperat...
      Aun así, suena rarísimo. Por un lado, claro que deberías recibir el rendimiento que te anunciaron y por el que pagaste; por otro, operar un CPU a 90~100°C se siente como una locura. Da la impresión de que Intel está bastante acorralada. Me da curiosidad saber qué configuración de enfriamiento usa
    • No me gusta el marketing del turbo boost
      Es como cuando antes los ISP vendían “hasta X Mbps”. Este chip también dice que puede hacer turbo boost “hasta 6.00GHz”
      En la práctica es overclock automático y, como ya viste, a veces ni siquiera puede sostener esa velocidad de forma estable. Algunos chips jamás van a funcionar a “hasta 6.00GHz”, pero técnicamente no es mentira. Porque es “hasta”
    • Hace poco armé un sistema con una motherboard ASUS TUF, un cooler NZXT Kraken 360 y un 14900KF, y hasta ahora no he tenido problemas con la configuración predeterminada del BIOS. De fábrica estaba en 5.7GHz y nunca he visto que la temperatura pase de 70°C
      Eso sí, tampoco he visto que la carga del CPU pase de 40%, ni he corrido software de benchmark. Lo de 90°C a 5.4GHz suena bastante distinto a lo que veo en mi procesador, así que me da curiosidad qué refrigeración usas. También puede ser que, aunque tenga clocks más altos, yo simplemente no haya exigido tanto el CPU
    • Me pregunto si ya limpiaste todo bien y volviste a montar el cooler con pasta térmica nueva. He visto un comportamiento parecido cuando la pasta quedó mal aplicada y se formaron burbujas de aire. ¿Las lecturas de temperatura por núcleo muestran diferencias grandes?
    • Da miedo pensar que una diferencia del 10% en frecuencia de reloj sea lo que separa la estabilidad de la inestabilidad. ¿Cuánto margen real queda?

  • Esto recuerda el clásico artículo de Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20050412-47/?p=35...

    • Me pregunto por qué no añadieron al analizador de fallos del sistema un componente que le dijera al usuario que la CPU está funcionando de forma anómala. Por ejemplo, si avisara que incluso una instrucción básica como xor eax, eax está fallando, se podrían reducir las solicitudes de soporte difíciles de depurar

  • Esta situación me resulta familiar. Me hace pensar en el viejo Pentium III 1.13GHz
    https://www.tomshardware.com/reviews/intel-admits-problems-p...

    • Aparte del tema principal, hay que reconocer que Tom’s Hardware sigue sirviendo perfectamente una publicación web de hace 24 años

  • En Zstd también nos topamos regularmente con problemas de hardware. A menudo, el descompresor termina siendo el primer componente que interactúa con los datos que llegan por la red
    Como en este caso, el descompresor es extremadamente sensible a los bit flips, independientemente de si se usan checksums, así que muchas veces detecta problemas de hardware antes que otros procesos que corren en el mismo host
    Zstd decidió incluir solo un checksum de los datos originales, y eso basta para garantizar la integridad de los datos. Pero como no permite verificar si los datos comprimidos se corrompieron, se vuelve más difícil descartar que la causa de la corrupción sea el descompresor

    • Los datos comprimidos son como los respaldos: no son válidos hasta que se verifican

  • Esta página no parece estar enlazada desde otras páginas públicas, así que da la impresión de que fue creada para responder a quejas no deseadas de usuarios que intentaban rastrear “oodle” en los registros de error. Algo parecido a lo de SQLite en 2006 [1]
    [1] https://news.ycombinator.com/item?id=36302805

  • No me sorprende en absoluto
    En su momento compré una ASUS TUF board para un 4790K porque quería algo básico y no me interesaba el overclock ni andar ajustando cosas. Pero el BIOS pensaba distinto
    Solo para evitar el overclock tuve que configurar manualmente una gran cantidad de opciones, poner los timings de la RAM y revisar cada entrada del BIOS para asegurarme de que no estuviera overclockeando de algún modo. La configuración “optimal” activaba cambios agresivos, como ajustar multiplicadores de velocidad del bus

    • Como dicen otros, esa CPU “lo bastante básica” en realidad apunta de lleno al mercado del overclock, y la placa que elegiste probablemente también. No es una configuración básica en absoluto, sino un sistema para ajuste avanzado. Solo que es un sistema de ajuste avanzado de hace 10 años
    • Es raro que alguien compre un procesador K si no le interesa el overclock ni el ajuste fino. No me sorprendería que el BIOS de una placa gamer asuma eso al definir sus valores predeterminados “optimal”. El mercado gamer está muy centrado en los benchmarks

  • Me pasó algo parecido con una motherboard Asus. El auto tuning la volvía inestable y el compilador se caía, así que para usarla normalmente tuve que configurar el BIOS a mano
    Creo que el problema empeora por la forma en que el SuperIO controla los ventiladores, porque las caídas estaban relacionadas con picos de temperatura de 100°C. La subida de velocidad de los ventiladores es demasiado lenta y la bajada demasiado rápida
    En Linux eso se puede ajustar desde espacio de usuario. Pero en realidad, la fase de subida debería controlarse con indicadores adelantados como el regulador de voltaje, no con indicadores retrasados como la temperatura. O bien el controlador p-state de Linux podría predecir el nivel de potencia y fijar una mayor velocidad de ventilador

    • Estoy lidiando con este problema justo ahora. Mi configuración es Asus ROG Z790, 14900K, Noctua NH-D15
      La curva de ventilación predeterminada no sirve de mucho y además oscila constantemente, lo cual es molesto. La temperatura de un solo núcleo P sigue disparándose y los ventiladores reaccionan de forma errática
      Leí que aumentar el tiempo de subida suaviza el comportamiento de los ventiladores, pero por la experiencia anterior, eso podría incluso provocar fallos del procesador