O mais recente guia de revisão do processador da AMD para os chips de servidor EPYC 7002 ‘Rome’ revela um novo bug interessante (errata) que pode fazer com que um núcleo do chip trave após 1.044 dias de tempo de atividade (~ 2,93 anos), o que significa que você terá que redefinir o servidor para que o chip funcione corretamente. AMD diz que não vai resolver o problema.
A descrição do problema pela AMD, que afeta seus processadores EPYC de segunda geração (os chips Genoa de quarta geração da AMD são os mais novos), é sucinta, mas há muito o que descompactar.
A listagem da errata diz que um núcleo de chip EPYC Rome de 7 nm pode ou não travar após 1.044 dias (~ 2,93 anos). Isso não afetará a esmagadora maioria de seus usuários, embora alguns encontrem o problema (mais abaixo).
O problema decorre da falha do núcleo em sair do estado de suspensão CC6, mas a AMD diz que o tempo da falha pode variar com base no espectro de dispersão e na frequência REFCLK, o último dos quais é o relógio de referência que ajuda o chip a controlar o tempo.
usuário Reddit acid_migrain tem uma teoria plausível sobre o momento exato do travamento do núcleo, dizendo: “Apesar do que dizem, o problema realmente se manifesta em 1.042 dias e aproximadamente 12 horas. O TSC marca a 2.800 MHz e 2.800 * 10 ** 6 * 1.042,5 dias quase igual a 0x380000000000000, que tem muitos zeros para não ser uma coincidência.”
A correção é simples – reinicie antes de 1.044 dias de tempo de atividade ou desative o estado de suspensão CC6.
Embora esse bug seja interessante, esse tipo de errata de chip definitivamente não é incomum. As CPUs modernas são os dispositivos mais complexos construídos pela humanidade e quase sempre chegam ao mercado com inúmeras errata/bugs descobertos durante ou após os chips atingirem sua revisão final de envio (stepping).
Com bilhões de transistores em jogo, é inevitável que haja problemas: não é incomum que um chip tenha mil ou mais dessas errata que são corrigidas em revisões mais recentes do chip ou com ajustes de firmware antes do lançamento. No entanto, algumas errata sempre permanecem, mesmo nas fichas de envio. Por exemplo, a 8ª geração da Intel tem mais de 150 errata que ainda permanecem, e essas foram lançadas em 2017. Não sabemos quantas errata os chips de Roma tiveram, a AMD removeu as listas de errata que foram resolvidas. No entanto, sabemos que 39 errata permanecem, o que na verdade não parece tão ruim com o pano de fundo da Intel.
Algumas errata são deixadas sem reparo simplesmente porque não representam nenhum dano, mas além de errata crítica que poderia deixar um vetor de ataque aberto, algumas errata relacionadas à funcionalidade simplesmente nunca são corrigidas. O fabricante de chips pesa fatores como a gravidade da errata, a facilidade de corrigir o problema e se houver errata suficiente para merecer a criação de outra etapa – isso não é um esforço trivial.
Agora, embora esse bug de travamento do núcleo de 2,93 anos seja interessante, a questão é se isso realmente importa. Claro, é importante, apesar do fato de que atualizações de segurança e manutenção deve ser feito em muito, muito intervalos mais curtos.
Dito isso, sempre gostei de ler histórias sobre o misterioso servidor empoeirado no canto de uma empresa de médio porte que está lá há uma década, mas nunca foi fechado, simplesmente porque ninguém sabe que tipo de serviço está fornecendo e ninguém quer ser responsável por uma possível falha.
Mas, embora existam esses casos, o cenário mais realista seria simplesmente aquele que usa o recurso de correção ao vivo do Linux para atualizar sem reinicializar – isso certamente poderia levar ao tipo de tempo de atividade estendido que acionaria o bug porque você precisa redefinir a CPU para reiniciar seu cronômetro de 1.044 dias. Além disso, os servidores para aplicativos de missão crítica geralmente têm tempo de atividade estendido.
E há as pessoas que só querem se juntar ao clube de uptime e estabelecer um recorde. Para fazer isso, você tem que vencer o computador a bordo do espaçonave Voyager 2. Sim, aquele que foi o segundo a entrar no espaço interestelar. Esse computador está funcionando há 16.735 dias (mais de 48 anos) e contando.
Para registros mais terrestres, 6.014 dias (16 anos) parece ser o registro para um servidor, mas já vi muitos debates sobre outros candidatos à coroa. (O pequeno /r/uptimeporn/Reddit community tem muitos exemplos de tempo de atividade prolongado.)
Em ambos os casos, você não poderá testar esse tipo de registro com nenhum dos chips EPYC Rome – esta errata não será corrigida, portanto, nem todos os seus núcleos excederão o limite de 1.044 dias em muito, se é que o farão, em qualquer circunstância. A AMD obviamente decidiu que o problema é muito caro para corrigir no silício, ou talvez uma correção de microcódigo/firmware tenha muita sobrecarga de desempenho ou simplesmente não haja clientes afetados o suficiente.
Por que a AMD não o encontrou antes? Bem, 2,93 anos é muito tempo e os chips AMD EPYC Rome foram lançados no final de 2018. Isso significa que pelo menos um dos clientes da AMD já encontrou o problema.