Falha de descompressão do 'Oodle' causada por instabilidade em processadores Intel

 (radgametools.com)
1 pontos por GN⁺ 2024-02-25 | 1 comentários | Compartilhar no WhatsApp
  • A instabilidade de hardware dos processadores Intel Core de 13ª e 14ª geração pode se manifestar em jogos baseados na Unreal Engine como falhas de descompressão do Oodle Data e travamentos
  • O erro mais representativo é DecompressShader(): Could not decompress shader (GetShaderCompressionFormat=Oodle), e o problema está relacionado não ao Oodle em si, mas a cargas de trabalho multithread intensas em geral que exigem muito da CPU
  • Travamentos também podem ocorrer em Adobe Premiere, RealBench, CineBench, Prime95, Handbrake e Visual Studio, e apesar de a causa ser a CPU, podem parecer erros de GPU, como out of video memory
  • A Intel confirmou que a causa é o envelhecimento acelerado do circuito interno de sinal de clock do chip devido à sobreposição de vários problemas, e componentes já fisicamente degradados precisam ser substituídos
  • Em 1º de outubro de 2024, começaram a ser distribuídas atualizações de BIOS para evitar as condições de operação que causam o dano, por isso elas devem ser instaladas antes que os sintomas apareçam

Instabilidade da CPU que aparece como travamento em jogos

  • Problemas de hardware nas séries 13xxx e 14xxx dos processadores Intel Core de 13ª e 14ª geração podem levar a instabilidade geral do sistema
  • Em jogos baseados na Unreal Engine, podem ocorrer falhas de descompressão do Oodle Data e travamentos
    • Erro representativo: DecompressShader(): Could not decompress shader (GetShaderCompressionFormat=Oodle)
  • Esse fenômeno não se limita ao Oodle
    • Programas que usam fortemente o processador em vários threads também podem apresentar travamentos ou comportamento imprevisível
    • Travamentos também foram observados em Adobe Premiere, RealBench, CineBench, Prime95, Handbrake e Visual Studio
  • Mesmo quando a causa é a CPU, podem aparecer mensagens que fazem parecer um problema de GPU
    • Ex.: erro incorreto de out of video memory

Causa e medidas necessárias

  • A Intel identificou a causa raiz como o envelhecimento acelerado do circuito interno de sinal de clock do chip
    • Vários problemas combinados acabam causando danos ao circuito
    • O dano é desgaste físico do próprio chip e, uma vez iniciado, não pode ser revertido
  • Componentes que já sofreram degradação precisam ser substituídos
    • O procedimento de substituição está resumido neste guia
  • Em 1º de outubro de 2024, começou a distribuição de novas atualizações de BIOS para evitar as condições de operação que causam danos ao circuito
    • Em notebooks e desktops prontos de fábrica, os fabricantes já estão distribuindo ou devem distribuir em breve atualizações de BIOS com essa mitigação
    • Em PCs montados pelo usuário, é preciso verificar a imagem de BIOS atualizada no site do fabricante da placa-mãe
  • A atualização de BIOS deve ser instalada antes que os sintomas apareçam
    • Depois que os travamentos começam, já é tarde demais para resolver apenas com software

Leituras relacionadas

1 comentários

 
GN⁺ 2024-02-25
Opiniões no Hacker News

  • Isso me lembrou um episódio que enfrentei quando adotei inicialmente o AMD Threadripper 3970X: https://forum.level1techs.com/t/amd-threadripper-3970x-under...
    Discussão no HN: https://news.ycombinator.com/item?id=22382946
    No fim, passamos meses investigando o problema junto com a AMD e, embora a AMD tenha me compensado generosamente pelo transtorno de ficar enviando e recebendo a placa-mãe e a CPU, desde então continuo usando uma imagem de BIOS customizada fornecida pela AMD. No fim das contas, parece que era um problema da Gigabyte

  • Recebi um 13900K com defeito e posso confirmar que, pelo menos no meu caso, o problema aparecia até com as configurações padrão de PL1/PL2
    Eu rodava aprendizado por reforço nesse sistema e ele travava continuamente, então passei bastante tempo tentando descobrir a causa; quando troquei a CPU por um 13700KF que eu usava em outro PC, o problema foi resolvido
    Quando solicitei RMA à Intel, disseram que a placa-mãe MSI que eu usava não dava suporte a Linux; quando enviei o repositório oficial da Intel no GitHub com o microcódigo que habilita o suporte, trocaram o atendente responsável. Naquele momento ficou bem claro que a Intel estava tentando evitar o RMA ao máximo e, felizmente, como moro na Europa, consegui conduzir o RMA por meio do órgão local de defesa do consumidor
    Nesse meio-tempo, vi uma promoção em uma loja online de um kit com 7950X e placa-mãe e comprei; vendi usados a placa-mãe antiga e o 13900K recebido no RMA. Eu usava Intel porque a Intel patrocinava alguns projetos de ciência de dados, mas não pretendo comprar Intel nunca mais

    • Meu 7700K também ficou instável desde a compra, e 16 meses de atualizações de BIOS não resolveram. Talvez os processadores das gerações mais recentes sofram com mais problemas do que os designs simples de antigamente

  • Para reduzir problemas de segurança, parece que é preciso desligar o hyper-threading; agora, para reduzir problemas de corrupção de memória, também parece que é preciso desligar o modo turbo
    Se você também desliga os estados C para evitar ataques por canal lateral e desliga os núcleos de eficiência para evitar problemas no escalonador, em algum momento acaba voltando a um conjunto de recursos de 20 anos atrás :P

    • O problema parece surgir das diferenças de firmware entre vários fabricantes de placas-mãe. Uso uma placa-mãe com Ryzen 7950X e ela aleatoriamente não dava boot; era preciso remover a bateria e fazer um reset completo para voltar a funcionar. No fim, uma atualização de firmware corrigiu esse bug
    • É só desligar o overclock
    • Naquela época, eles sabiam fazer hardware confiável, em vez de enfiar recursos pouco validados e tentar atingir números de ponta com concessões duvidosas
    • Sinceramente, talvez o mundo fosse melhor se tivéssemos parado no Coppermine ou no Tualatin e focado apenas em melhorar o software
    • Bom, rápido e barato. Escolha apenas dois dos três

  • Recentemente montei um sistema novo com um i9 149KF e uma placa-mãe Asus Formula. A ideia era rodar Windows em um sistema VFIO e também jogar
    Fazer tudo funcionar de forma estável foi um pesadelo, e nenhuma das configurações padrão da placa-mãe estava correta. Os jogos travavam, e a compilação do kernel e do Emacs também falhava
    No fim, precisei limitar o turbo do chip de 6 GHz a 5,4 GHz e ativar configurações que limitam a potência máxima e a temperatura de throttling a 90°C
    Agora parece estável, sustenta 5,4 GHz sem throttling e estou jogando em 4K a 120 fps. Ainda assim, incomoda o fato de que, sob nenhuma configuração, consigo rodar nos números anunciados pelos quais paguei

    • Ao dizer que limitou a temperatura de throttling a 90°C, isso significa que antes ela passava de 90°C?
      No começo achei absurdo, mas, segundo a Intel, parece ser normal para esse chip: “O processador suporta até 100°C, e qualquer temperatura abaixo disso é normal e está dentro do intervalo esperado”
      https://community.intel.com/t5/Processors/i9-14900K-temperat...
      Mesmo assim, é muito estranho. Por um lado, é óbvio que você deveria receber o desempenho anunciado e pelo qual pagou; por outro, operar uma CPU a 90–100°C parece loucura. Dá a impressão de que a Intel está bem pressionada. Fico curioso para saber que configuração de resfriamento você está usando
    • Não gosto do marketing do Turbo Boost
      É igual ao jeito como os ISPs vendiam antigamente “até X Mbps”. Esse chip também diz que faz Turbo Boost “até 6,00 GHz”
      Na prática, é overclock automático e, como você viu na pele, às vezes ele nem consegue entregar essa velocidade de forma estável. Alguns chips nunca vão operar a “até 6,00 GHz”, mas não é mentira. Afinal, é “até”
    • Recentemente montei um sistema com uma placa-mãe ASUS TUF, um cooler NZXT Kraken 360 e um 14900KF, e até agora não tive problemas com as configurações padrão da BIOS. O padrão era 5,7 GHz, e não vi a temperatura passar de 70°C
      Por outro lado, também não vi a carga da CPU passar de 40% e não rodei nenhum software de benchmark. 5,4 GHz a 90°C é bem diferente do que vejo no meu processador, então fico curioso para saber que solução de resfriamento você usa. Mesmo com clocks mais altos, talvez eu simplesmente não tenha forçado tanto a CPU
    • Fico me perguntando se você já limpou tudo e remontou o cooler com pasta térmica nova. Já vi comportamento parecido quando a pasta foi aplicada errado e formou bolhas de ar. As leituras de temperatura por núcleo aparecem muito diferentes entre si?
    • É assustador pensar que uma diferença de 10% na frequência de clock pode separar a estabilidade da instabilidade. Quanta margem real ainda resta?

  • Lembrei de um texto clássico do Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20050412-47/?p=35...

    • Fico me perguntando por que não colocaram no analisador de crashes do sistema um componente que avisasse ao usuário quando a CPU estivesse se comportando de forma anômala. Por exemplo, se ele informasse que até uma instrução básica como xor eax, eax está errada, poderia ter reduzido chamados de suporte difíceis de depurar

  • Essa situação é familiar. Lembra o antigo Pentium III 1.13GHz
    https://www.tomshardware.com/reviews/intel-admits-problems-p...

    • À parte do tema original, é elogiável que o Tom’s Hardware ainda sirva perfeitamente uma publicação da web de 24 anos atrás

  • Também encontramos problemas de hardware regularmente no Zstd. Muitas vezes o descompressor acaba sendo o primeiro componente a interagir com dados vindos pela rede
    Como neste caso, descompressores são muito sensíveis a bit flips, independentemente de usarem checksum ou não, então muitas vezes percebem problemas de hardware antes de outros processos rodando no mesmo host
    O Zstd decidiu incluir apenas o checksum dos dados originais, o que é suficiente para garantir a integridade dos dados. Mas, como não dá para verificar se os dados comprimidos foram corrompidos, fica mais difícil descartar que a origem da corrupção seja o descompressor

    • Dados comprimidos são como backups. Não são válidos até serem verificados

  • Esta página não parece estar linkada a partir de outras páginas públicas, então parece uma página criada para responder a reclamações indesejadas de usuários tentando rastrear “oodle” nos logs de erro. Parecido com o caso do SQLite em 2006 [1]
    [1] https://news.ycombinator.com/item?id=36302805

  • Nada surpreendente
    Há algum tempo comprei uma placa ASUS TUF para um 4790K porque queria algo básico e não tinha interesse em overclock nem ajustes finos. Mas o BIOS tinha outra ideia
    Só para evitar overclock, precisei configurar manualmente inúmeras opções, ajustar os timings da RAM e verificar cada item do BIOS para garantir que ele não estivesse fazendo overclock de alguma forma. As configurações “optimal” ativavam mudanças agressivas, como ajuste do multiplicador da velocidade do barramento

    • Como outras pessoas disseram, essa CPU “básica o suficiente” na verdade é um produto voltado diretamente ao mercado de overclock, e a placa-mãe mencionada provavelmente também. Não é uma configuração básica de forma alguma; é um sistema para ajustes avançados. Só que é um sistema de ajustes de 10 anos atrás
    • É raro alguém comprar um processador K sem interesse em overclock e ajustes. Não surpreende se o BIOS de uma placa-mãe gamer definir os padrões “optimal” partindo dessa premissa. O mercado gamer é centrado em benchmarks

  • Passei por algo parecido em uma placa-mãe Asus. O auto-tuning a deixava instável e fazia o compilador travar; para usar normalmente, precisei configurar o BIOS manualmente
    Acho que o problema piora pela forma como o SuperIO controla o cooler, porque os crashes estavam associados a picos de temperatura de 100°C. A ventoinha sobe devagar demais e desce rápido demais
    No Linux, dá para ajustar isso no espaço de usuário. Mas, na prática, quem deveria controlar a fase de subida não é um indicador atrasado como temperatura, e sim um indicador antecipado como o regulador de tensão. Ou então o controlador p-state do Linux poderia prever o nível de potência e definir uma rotação de ventoinha mais alta

    • Estou passando por exatamente esse problema agora. A configuração é Asus ROG Z790, 14900K, Noctua NH-D15
      A curva padrão das ventoinhas não é eficaz e fica oscilando sem parar, o que irrita. A temperatura de um único P-core fica dando saltos, e as ventoinhas reagem de forma dispersa
      Li que aumentar o tempo de subida suaviza o comportamento das ventoinhas, mas, pela experiência acima, isso também pode acabar causando falha no processador