1 pontos por GN⁺ 2024-07-24 | 1 comentários | Compartilhar no WhatsApp
  • A Intel concluiu, a partir da análise de processadores desktop Core de 13ª/14ª geração devolvidos, que a instabilidade em alguns produtos está relacionada a altas tensões de operação
  • A causa foi identificada como um algoritmo de microcódigo que envia solicitações incorretas de tensão ao processador
  • A Intel está preparando um patch de microcódigo para corrigir a causa raiz da exposição a alta tensão e pretende liberá-lo para parceiros em meados de agosto, após a validação completa
  • Clientes que tiveram ou estão tendo sintomas de instabilidade podem receber suporte no processo de troca
  • Os canais de atendimento variam conforme a forma de compra: sistemas OEM/System Integrator devem contatar o vendedor, produtos boxed devem contatar o Intel Customer Support, e CPUs tray devem contatar o local de compra

Causa da instabilidade

  • A Intel realizou uma análise ampla de processadores desktop Core de 13ª/14ª geração devolvidos por problemas de instabilidade
  • Em alguns produtos, concluiu-se que a alta tensão de operação é um fator que provoca a instabilidade
  • A análise dos processadores devolvidos confirmou que a alta tensão de operação se origina de um algoritmo de microcódigo que envia solicitações incorretas de tensão ao processador

Plano de patch de microcódigo

  • A Intel pretende fornecer um patch de microcódigo para corrigir a causa raiz da exposição a alta tensão
  • Em relação aos processadores desktop Core de 13ª/14ª geração, a Intel continua realizando validações para verificar se os cenários de instabilidade relatados foram resolvidos
  • Após concluir toda a validação, a meta é liberar o patch para parceiros em meados de agosto

Suporte para troca ao cliente

  • A Intel informou que clientes que tiveram ou estão tendo sintomas de instabilidade em processadores desktop de 13ª e/ou 14ª geração poderão receber suporte no processo de troca
  • O procedimento de suporte varia conforme a forma de compra
    • Compradores de sistemas desktop OEM/System Integrator devem entrar em contato com a equipe de suporte ao cliente do vendedor do sistema
    • Compradores de processadores desktop boxed de 13ª/14ª geração devem entrar em contato com o Intel Customer Support
    • Compradores de processadores desktop tray de 13ª/14ª geração devem entrar em contato com o local de compra

Atualizações posteriores

1 comentários

 
GN⁺ 2024-07-24
Opiniões no Hacker News
  • Na prática, é difícil acreditar na explicação de que seja um problema de microcódigo
    A Intel tem um incentivo enorme para atribuir isso a um problema de microcódigo. Se bastar empurrar um patch, dá para corrigir de graça; mas, se for um defeito real de hardware, teria de fazer recall das CPUs defeituosas, o que poderia custar dezenas de bilhões de dólares
    Além disso, ficaram em silêncio por tempo demais. Se fosse um problema simples em que um microcódigo com bug solicita à placa-mãe uma tensão fora da especificação, bastaria colocar logging de tensão no VRM da placa-mãe para detectar rapidamente e corrigir em poucas semanas. Segundo algumas fontes, a Intel já estaria enviando CPUs sem defeito há meses, se não me engano desde abril, e esses produtos não tiveram o microcódigo atualizado
    Esse longo atraso dá a impressão de que passaram meses em P&D criando uma nova especificação de tensão, tentando contornar um defeito de hardware no maior número possível de produtos, ao mesmo tempo minimizando perda de desempenho ou novos erros causados por subtensão
    Esta atualização de microcódigo provavelmente só vai “corrigir” travamentos em algumas CPUs e, daqui a mais ou menos um mês, a Intel deve dizer que na verdade havia dois problemas independentes e, a contragosto, fazer recall dos produtos que não foram resolvidos pelo microcódigo

    • Pelo que entendo, há várias tensões dentro da CPU, então monitorar apenas o VRM da placa-mãe não é suficiente
      Ainda assim, estou bastante cético, por isso suspendemos temporariamente a compra de Intel 13ª/14ª geração na empresa e estamos esperando evidências reais de que o problema foi totalmente resolvido
    • O mais provável é que seja um problema de hardware e, ao mesmo tempo, um problema de microcódigo
      A fabricação de CPUs é parecida com selecionar ovos. Os chips produzidos têm características ligeiramente diferentes e são classificados em faixas conforme o quanto atendem às especificações
      Simplificando, chips “melhores” aguentam clocks ou tensões mais altos e são vendidos mais caro. Se houver um grão de poeira no die, parte da funcionalidade é desativada e ele é vendido por um preço menor
      Neste caso, é bem provável que sejam casos limítrofes que não teriam sido considerados defeitos se o microcódigo enviado já os tivesse tratado. Ainda assim, vale questionar se os chips afetados deveriam originalmente ter entrado em uma faixa de preço mais baixa
    • O motivo de terem sido necessários meses de P&D para criar um workaround pode ser que algumas placas-mãe que provocam esse problema tenham um comportamento limítrofe ou inesperado no gerenciamento de tensão
      Contornar esse comportamento no microcódigo da CPU não é trivial. Como o erro não parece ocorrer em todos os modelos de placa-mãe, o comportamento da placa-mãe parece ser pelo menos um dos fatores
    • CPUs modernas já saem de fábrica com inúmeros bugs. As erratas publicadas são apenas as descobertas depois do envio e, com sorte, todas elas são divulgadas. Muitos bugs são corrigidos durante os testes e a validação antes do envio
      O projeto de CPUs é feito empurrando o máximo possível para firmware e inserindo chicken switches, caminhos alternativos e mecanismos que interceptam o funcionamento normal e o transformam em traps de microcódigo, flushes e operações com perda de desempenho
      Correções ou workarounds podem ter um custo de desempenho considerável. Um exemplo clássico é desativar alguns preditores de desvio como mitigação para Spectre. Mesmo em erratas públicas, às vezes bugs de correção teórica são simplesmente deixados sem correção. É muito nebuloso definir a partir de que ponto deveria haver devolução do produto
      A regulação de tensão provavelmente é em grande parte configurável, junto com frequência, temperatura e throttling lógico, e há uma boa chance de ser controlada por um microcontrolador totalmente programável dentro do chip. O que fica gravado no silício pode ser algo como sensores de tensão/droop e sensores de temperatura, e esses também podem se comportar de maneira inesperada. Ainda assim, pode haver redundância ou meios de compensar pequenos desvios
      Não vejo isso como a Intel “empurrando a culpa para um problema de microcódigo”. Ela apenas disse que pode ser corrigido com um patch de microcódigo. Visto de fora, é muito difícil saber o que pode ser razoavelmente corrigido por microcódigo e o que deve ser chamado de problema de microcódigo. Por design, muitas coisas podem ser corrigidas por firmware ou patches de microcódigo, e de fato são corrigidas assim
      Por exemplo, se o circuito do sensor de tensão do chip se comporta de forma um pouco diferente do previsto no projeto, mas pode ser compensado adicionando um offset a uma tabela, o “problema” é que o silício se desviou do modelo ou do projeto, e o silício em si não pode ser alterado. Mesmo assim, uma atualização de firmware pode ser uma correção totalmente adequada, a ponto de nem valer a pena refazer o sensor mesmo em um novo mask spin
      Sobre o problema de tensão, a Intel também não disse que a CPU solicitava tensão fora da especificação, mas sim que era “incorreta”. Isso não é algo facilmente detectável sem contexto. Escalonamento dinâmico de tensão e frequência e problemas analógicos relacionados são extremamente complexos. A tensão solicitada ao regulador não é igual à tensão efetivamente vista por componentes específicos do chip, e carga, chaveamento, capacitância, frequência, temperatura etc. influenciam tudo
      CPUs modernas operam o mais próximo possível da margem mínima de tensão e timing para aumentar a eficiência, e fazem boost até tensões tão altas quanto possível para desempenho. Em um algoritmo complexo composto por muitas variáveis e grandes tabelas multidimensionais, um pequeno bug ou erro nos dados de caracterização já pode fazer tensão e timing saírem da especificação e causar instabilidade. Como não dá para medir continuamente a tensão de dezenas de bilhões de componentes dentro do chip, também não fica um log de debug limpo
      Alguns bugs simplesmente demoram para ser encontrados e corrigidos. Embora não tenha sido na Intel, já encontrei em uma CPU comercial um bug lógico que era rapidamente reproduzível e travava rigidamente uma unidade interna do núcleo, e ainda assim levou semanas. Um bug analógico transitório escondido nos cantos da faixa de operação pode ser muito mais difícil
      Depois disso, é preciso criar a correção real e rodar testes bastante rigorosos para ter uma confiança razoável de que o problema foi resolvido antes de anunciar. Isso acrescenta mais algumas semanas
      Não estou descartando a possibilidade de a Intel estar sendo desonesta ou ter más motivações, mas com as informações atuais é impossível fazer essa suposição. Este anúncio soa bastante plausível
    • A água já ficou turva o suficiente para que talvez evitem um recall completo e só respondam aos casos em que alguém apresente evidências de que o sistema ainda trava
  • https://scholar.harvard.edu/files/mickens/files/theslowwinte...
    “Infelizmente para John, as ramificações tinham feito um pacto com Satanás e com a mecânica quântica [...] Em troca do último fragmento restante de entropia, as ramificações lançaram feitiços malignos sobre as futuras gerações de processadores. Os nomes desses feitiços eram coisas como ‘vazamento de tensão induzido por scaling’ e ‘calor residual crescente’ [...] As ramificações, inimigas derrotadas havia muito tempo, ririam por último”
    “John ficou aterrorizado com o colapso da bolha de paralelismo e rapidamente abandonou o plano para o processador de 743 núcleos ‘The Hydra of Destiny’, no qual, por um breve momento em Gary, Indiana, um ideal platônico abstrato foi o terceiro melhor enxadrista. Com uma garrafa de uísque em uma mão e uma espingarda na outra, John vasculhou a literatura de pesquisa em busca de uma ideia que salvasse o sonho do scaling infinito. Ele encontrou vários artigos sobre recuperação de hardware auxiliada por software. A ideia básica era simples. Se, à medida que o hardware fica menor, as falhas transitórias aumentam, por que não fazer o software detectar cálculos incorretos e executá-los novamente? A ideia parecia promissora até John perceber que ela era a pior ideia de todos os tempos. Software moderno mal funciona mesmo quando o hardware está correto, então encarregar o software de corrigir erros de hardware é como pedir ao Godzilla que impeça o Mega-Godzilla de aterrorizar o Japão. Isso não leva a uma valorização imobiliária em Tóquio. Para começo de conversa, é melhor parar o scaling de transistores e não brincar com monstros. Melhor do que criar um sistema sofisticado de freios e contrapesos para monstros e torcer para que eles não façam o que sempre fizeram. Porque, se não fizessem essas coisas, seriam chamados de dentes-de-leão ou abraços de filhotes”

    • É a primeira vez que leio esse texto, mas, assim que cheguei mais ou menos ao meio, soube imediatamente que devia ter sido escrito por Mickens
    • O trecho “segundo meu pai, antigamente era divertido viajar de avião... todo mundo era atraente...” me faz lembrar os Superchargers de carros elétricos de hoje
      Claramente há um aspecto de privilégio, e algumas pessoas atraentes se beneficiam disso de maneiras previsíveis, além de desfrutarem de outros cuidados caros para manter a saúde e a aparência. Talvez acabemos dizendo a mesma coisa aos nossos filhos no futuro
  • Ainda precisamos ver que impacto o patch de microcódigo terá no desempenho e como CPUs afetadas a ponto de ficarem instáveis por sobretensão vão envelhecer daqui a 6 meses ou alguns anos
    Em geral, aplicar mais tensão aumenta a margem de temporização e melhora a estabilidade. Ficar instável em alta tensão sugere um nível perigoso. Um patch de software pode reduzir a tensão daqui para frente, mas não consegue desfazer a fadiga acumulada que já se formou

    • A Intel afirma que o patch final causa queda de desempenho de 4% https://youtu.be/wkrOYfmXhIc?t=308
    • Recentemente montei alguns sistemas e pesquisei para comprar outros; sempre gostei da Intel, mas desta vez fui de AMD
      A diferença entre a frequência base e a frequência de boost da Intel parecia, na maior parte dos casos, muito maior que a da AMD. Especialmente em notebooks, onde a refrigeração é uma restrição maior, tive a impressão de que estavam forçando os limites
      A configuração de núcleos de desempenho e núcleos de eficiência também pareceu meio uma brincadeira, por ter poucos núcleos de desempenho e muitos de eficiência. Dizem “processador de 20 núcleos!”, mas, do ponto de vista de desempenho, na prática é um 8 núcleos. Fica difícil comparar com um Ryzen de 12 núcleos, clock mais alto e cache 3D
      Ainda assim, a Intel pode ter algumas vantagens restantes. A AMD parecia ter problemas com suporte a ECC nos chipsets atuais, e por causa disso quase fui de Intel. No fim, concluí que a correção de erros integrada do DDR5 seria suficiente. Os gráficos de desempenho também mostram uma vazão mais suave, o que faz parecer uma execução mais eficiente ou elegante, isto é, com menos gargalos. Em média, porém, a AMD também parece chegar a resultados finais semelhantes, mesmo que os gráficos sejam um pouco mais serrilhados
    • Talvez seja um salto meio grande, mas isso me lembra o controle da glicemia em pacientes com diabetes tipo 1
      Se estiver baixa demais, é perigoso porque a pessoa perde a capacidade de pensar racionalmente, manter a consciência e se recuperar por conta própria. Mas, mesmo sem o risco imediato da glicemia baixa, o que causa danos aos órgãos ao longo do tempo é a glicemia alta
  • Parece significativo que estejam adiando o patch de microcódigo para depois que os reviewers do Zen5 publicarem todas as análises comparando com o desempenho do Raptor Lake atual

    • Por que publicar análises comparativas? Processadores Raptor Lake não são produtos em funcionamento normal para serem usados como alvo de benchmarks
  • Isso me lembra a Sudden Northwood Death Syndrome de 2002
    A história parece se repetir, ou pelo menos rimar
    Na época, as CPUs operavam com tensão fixa e frequência fixa, e só os overclockers encontravam os limites. Mesmo então, eram raros os relatos de CPUs morrendo por sobretensão, exceto em casos extremos. Antes de danos reais, pareciam ocorrer primeiro thermal throttling, instabilidade e desligamento (THERMTRIP), impedindo o dano
    Agora, os fabricantes de CPUs tentam extrair o máximo desempenho possível e, na prática, aplicam overclock e sobretensão automática e dinamicamente via firmware/microcódigo. Não seria surpreendente se um bug que negligenciou a confiabilidade, ou uma decisão deliberada de ignorá-la, tivesse passado do ponto. A Intel talvez tenha sido mais conservadora com a tensão máxima absoluta até recentemente, e há também o fato de que processos menores aumentam a possibilidade de eletromigração, elevando a vulnerabilidade
    Como anedota, usei uma CPU móvel de 8ª geração com todos os limites de energia removidos, em tensão padrão, rodando 24 horas por dia por mais de 5 anos colada no limite térmico de 100 graus, e ela ainda é 100% estável. Casos de CPUs usadas por anos com o dissipador entupido, ou até solto, parecem reforçar a evidência de que o que mata CPUs não é calor nem frequência, mas tensão alta
    Fui procurar o VCore máximo dos processadores de 13ª/14ª geração e o datasheet diz 1,72 V. É muito mais alto do que eu esperaria para um processo de 10 nm. Para comparação, o i7 de 1ª geração em 45 nm tinha máximo absoluto de 1,55 V; na versão de 32 nm, caiu para 1,4 V; e na versão de 22 nm, subiu um pouco para 1,52 V

    • Nostalgia pura. Eu usava um Athlon com núcleo Thunderbird, cuja frequência padrão, se me lembro bem, era 1050 MHz
      Era estável a 1600 MHz, e usei assim por alguns anos. Dava para subir até 1700 MHz, mas a partir daí a estabilidade da CPU dependia da temperatura ambiente. No verão, quando o quarto esquentava, a workstation dava kernel panic aleatoriamente
    • Acho interessante, porque nunca tinha ouvido falar de problemas de overclock no Pentium. Minha hipótese sobre o problema atual é que rodar o chip por longos períodos a 100 graus não faz bem para a vida útil, mas a tensão também pode ser o problema
      Pensei nisso no verão passado, quando montei um sistema com um 13900K e ajustei as configurações com a intenção de usar a CPU por 10 anos
      Anedoticamente, minha CPU roda muitos jogos e compila bastante, e não percebi problemas de estabilidade. Coloquei o limite de energia em 150 W, perdendo um pouco de desempenho, mas não muito
    • Pelo que lembro, a primeira explicação da Intel foi jogar a culpa nos fabricantes de placas-mãe, dizendo que eles tentavam fazer overclock “automático” nessas CPUs
  • Recentemente houve comentários de que chips móveis de 13ª/14ª geração teriam problemas semelhantes, mas a Intel alegou que era outro problema
    Vai ser interessante ver como isso se desenrola
    [1]: https://news.ycombinator.com/item?id=41026123

    • O problema em mobile parece mais anedótico do que baseado em dados. Dá a impressão de alguém que ouviu no Reddit que CPUs de 13ª/14ª geração são ruins e, quando o notebook travou, concluiu: “aconteceu comigo também”
    • Será que CPUs de servidor não têm problema semelhante, ou a Intel sabe que compradores de servidores não seriam tão tolerantes?
      A perspectiva de comprar Intel enquanto me pergunto se vou conseguir esperar 5 anos até a substituição, comparado a algumas gerações atrás, não é muito animadora. Dito isso, as opções de servidores AMD também podem ser um tanto limitadas, e eu também não sei bem como avaliar a probabilidade de haver mais problemas surpreendentes no geral
  • Depois de assistir a https://youtube.com/watch?v=gTeubeCIwRw e ao conteúdo relacionado, pessoalmente não acredito que seja um problema que dê para corrigir com microcódigo. Vamos ver

    • O HN não oferece prévia de links, então é melhor incluir um pouco de descrição do conteúdo no comentário. Caso contrário, é preciso clicar no YouTube para entender o comentário
      Esse vídeo é da GamersNexus e trata de uma alegação não verificada de que seria um problema no processo de fabricação causado por oxidação entre camadas de deposição atômica. Se isso for verdade, há um limite para o que o microcódigo pode fazer. Mas, como Steve diz no vídeo, a teoria da oxidação ainda não foi comprovada, e eles publicaram o que tinham reunido até agora antes das análises do Zen 5 que sairão em breve
  • As CPUs que receberam alta tensão de operação ficaram permanentemente danificadas?

    • Essa é a pergunta mais urgente. Se fosse apenas um problema de microcódigo, resfriar e desligar/ligar a máquina deveria ao menos resetar tudo, mas, segundo Wendel, da Level 1 Tech, parece que nem sempre é assim
    • Não parece ser algo que quebra imediatamente, mas há relatos de degradação ao longo do tempo. Deve variar caso a caso
    • Há possibilidade de dano por eletromigração
  • Estou muito satisfeito com meu 7800X3D. Ele roda a no máximo cerca de 70 graus, como os chips Intel antigos, um cooler a ar de 35 dólares dá conta, e atualmente é, em média, o chip mais rápido em cargas de jogos

    • Eu também estou muito satisfeito com meu 5800X3D. Foi um excelente custo-benefício na época em que o AM5 tinha acabado de sair e DDR5 e placas-mãe eram absurdamente caros
      Considerando as tarifas de eletricidade absurdas do Reino Unido, a eficiência energética é muito bem-vinda
  • Eu tinha receio de que algo assim acontecesse ao ver tanta energia sendo empurrada para os chips para manter a competitividade
    Parece que a inovação da Intel realmente desacelerou, ou que a AMD pensou vários passos à frente em tecnologia, marketing e patentes, encurralando a Intel
    Ainda assim, não acho que a Intel tenha acabado. Pelo menos ainda não