O problema está relacionado ao fato do kernel não sair do modo de economia de energia
Faz pouco informações foram divulgadas sobre um bug bbastante particular na série de processadores de servidor AMD EPYC 7002 (“Roma”) baseado na microarquitetura “Zen 2” distribuída desde 2018.
E é isso que está em causa na decisão faz com que o processador trave após 1044 dias de operação contínuo (uma situação bastante particular e que é um tanto incomum.
Um pequeno post de AMD indica que processadores de servidor de XNUMXª geração estão enfrentando um problema que impede que os núcleos saiam do modo de economia de energia Core C6 State (ou CC6) após um ciclo longo. Ao mesmo tempo, o fabricante alegou que 1044 dias não é um valor absoluto, pois a falha pode ocorrer mais cedo ou mais tarde, pois tudo depende da frequência de REFCLK, que permite que os processadores rastreiem o parâmetro de tempo e alguns outros fatores. Mas o fabricante não fornece nenhuma informação exatamente por que a falha ocorre, então ninguém entende exatamente qual é a raiz da falha até agora.
Fracasso como tal, coloca o processador em modo "zumbi", no qual não aceita nenhum comando ou solicitação de interrupção externa e permanece nesse estado a menos que seja reiniciado.
Esses modos de estado C começam em C0, que é o modo de operação normal da CPU. Quanto maior o número C, mais profundamente a CPU entra no modo de hibernação e mais sinais são desligados. Quanto mais profundo o estado de suspensão, mais tempo leva para a CPU acordar totalmente.
Com esse bug, uma vez que uma CPU entra em C6 após a marca de 1044 dias, ela fica travada e requer uma reinicialização. A solução é reiniciar o servidor antes de três anos ou desabilitar o estado de suspensão que está causando o erro.
A AMD não fornece uma explicação mais detalhada da causa da falha. A julgar pela suposição Postado no Reddit:
O travamento ocorre quando o contador no registrador TSC (Time Stamp Counter), que conta o número de ciclos de trabalho após o reset, na frequência de 2800 MHz atinge o valor 0x380000000000000 (2800 MHz * 10* *6 * 1042,5, 1042, isto é, após 12 dias e XNUMX horas).
Além disso, A AMD mencionou que a correção do bug não será lançada, já que o problema passou despercebido por muito tempo porque uptimes de vários anos não são típicos de servidores que precisam ser reinicializados periodicamente para instalar atualizações de kernel ou migrar para uma nova versão do sistema operacional para se manter atualizado.
No entanto, os métodos de atualização do kernel sem reinicialização das distribuições Linux e os longos ciclos de manutenção (Ubuntu, RHEL e SUSE são suportados por 10 anos) podem levar a longos tempos de espera para servidores sem reinicialização.
Representantes da empresa disseram que atualmente Existem duas opções para resolver o problema: lOs proprietários de servidores nesses processadores devem reinicie o sistema para redefinir o cronômetro para 1044 diasPortanto, desative completamente o modo de economia de energia Core C6 State. Provavelmente, ambas as opções são muito inadequadas para proprietários de processadores de servidor - modo de economia de energia, pois economiza muito dinheiro no consumo de energia, então obviamente ninguém vai desligá-lo e esperar que ocorra um erro e ele congele, reiniciando o sistema também não é uma solução muito conveniente. Especialmente quando se trata de alguns componentes de infraestrutura realmente importantes.
Cabe mencionar que este tipo de erros não são raros no segmento de processadores (independentemente de serem para servidores ou desktops), pois muitas vezes os modelos comerciais também contêm muitos bugs, mas depois tentam corrigi-los com uma nova revisão ou com correções baseadas em software e firmware.
Finalmente Se você estiver interessado em saber mais sobre isso, te convido a consultar a informação publicado pela AMD.