Códigos de diagnóstico UEFI POST: um guia completo e prático

Quando um computador ou servidor é ligado, a primeira coisa que entra em ação não é o sistema operacional, mas o firmware — ou seja, o pequeno bloco de código que reside na placa-mãe e decide se o computador está pronto para inicializar. Em sistemas modernos, esse papel geralmente é desempenhado pela UEFI, a sucessora da BIOS clássica, e uma de suas tarefas essenciais é executar o POST (Power-On Self Test), uma série de verificações que, se algo der errado, gera códigos de erro, bipes e mensagens que muitas vezes soam como incompreensíveis se você não souber como interpretá-las.

Os códigos POST da UEFI são essenciais para entender o problema: desde um módulo de RAM defeituoso até uma placa de vídeo desalinhada, um disco rígido danificado ou um erro de comunicação com o controlador de gerenciamento (BMC, IMM, SP, etc.). Compreender o que eles significam, como são registrados e quais ações cada fabricante ( Lenovo , IBM, Dell, Oracle, etc.) recomenda é fundamental tanto para técnicos quanto para usuários avançados que desejam diagnosticar seus computadores sem se perderem em jargões técnicos desnecessários.

O que são UEFI e POST e qual o papel que desempenham na inicialização de um computador?

UEFI (Unified Extensible Firmware Interface) é o padrão que substituiu o BIOS tradicional na maioria dos computadores e servidores modernos. Ao contrário do BIOS clássico, que operava em modo de 16 bits e era fortemente acoplado à ROM da placa-mãe, o UEFI pode residir em qualquer memória não volátil e funciona em modo protegido de 32 ou 64 bits, permitindo oferecer mais recursos, melhor desempenho e opções de segurança avançadas.

O POST (Power-On Self Test) é a "verificação médica" que o firmware realiza no hardware assim que o computador é ligado. Durante essa fase, componentes como o processador, a memória RAM, o chipset, a placa gráfica, o teclado, as unidades de disco e outros dispositivos essenciais são detectados e inicializados. Se tudo estiver funcionando corretamente, o firmware passa o controle para o carregador do sistema operacional; caso contrário, ele gera códigos de erro, mensagens na tela e padrões de bipes para indicar qual componente falhou.

Durante o POST, são realizados testes muito específicos : a CPU é verificada, o próprio firmware é verificado, a configuração salva na memória CMOS é lida, o temporizador do sistema (relógio interno) e o controlador DMA são inicializados, a RAM e o cache são verificados, módulos de firmware adicionais são carregados e periféricos básicos, como teclado e dispositivos de armazenamento , são detectados e configurados.

Se o POST encontrar uma anomalia menor , ele tenta continuar a inicialização , mas assim que detecta um erro crítico (por exemplo, falta de RAM utilizável, placa gráfica sem resposta ou falha da CPU), ele para e exibe um destes sinais: uma mensagem na tela se o subsistema de vídeo estiver funcionando, uma sequência de bipes com um padrão específico e/ou códigos POST enviados para portas internas ou registrados no controlador de gerenciamento do sistema.

Quando tudo está correto e não há falhas detectáveis, muitos firmwares emitem um único bipe curto que tradicionalmente tem sido interpretado como confirmação de que o POST terminou sem problemas e o dispositivo irá transferir o controle para o sistema operacional.

Códigos de diagnóstico POST da UEFI em servidores (IMM, SP, BMC, etc.)

Em muitos servidores modernos, os códigos de diagnóstico POST da UEFI não se limitam a mensagens na tela ou bipes, mas são registrados detalhadamente em módulos de gerenciamento integrados. A Lenovo, por exemplo, armazena esses códigos no log de eventos do IMM; outros fabricantes usam controladores chamados SP ou BMC, acessíveis por meio de interfaces como o Oracle ILOM ou similares.

Quando ocorre um evento POST, os guias do fabricante geralmente incluem um campo chamado "Resposta do Usuário ". Esta seção descreve, passo a passo, as ações recomendadas para tentar resolver o problema. A ideia é seguir as instruções na ordem apresentada e, se o erro persistir após a conclusão de todas as etapas, entrar em contato com o suporte técnico apropriado (Suporte Lenovo, Suporte IBM, etc.).

Os manuais de UEFI/POST de servidores compilam listas extensas de códigos de erro acompanhados de descrições e possíveis causas. Por exemplo, podem indicar se o erro está relacionado ao subsistema de memória, ao barramento PCIe, ao controlador de E/S, a problemas térmicos, a discos rígidos SAS/SATA, a falhas na bateria CMOS, a erros de senha e assim por diante.

Uma parte importante do diagnóstico envolve a revisão do registro de eventos do SP ou IMM . Nele, você encontrará mensagens mais detalhadas do que as exibidas na tela, frequentemente com informações adicionais: a porta ou slot afetado, o tipo exato de erro no barramento, o módulo de memória envolvido, os limites térmicos excedidos e até mesmo históricos de erros recorrentes que ajudam a identificar componentes intermitentes ou prestes a falhar.

Em alguns casos, um erro POST pode exigir apenas uma reinicialização simples do controlador de gerenciamento . Por exemplo, certas falhas de comunicação interna entre o firmware principal (BIOS/UEFI) e o SP/BMC podem gerar mensagens como "BMC não está respondendo", e a solução recomendada pode ser reiniciar o SP ou, se isso não resolver o problema, encaminhar o caso para o suporte para descartar uma falha física na placa ou no próprio módulo de gerenciamento.

Exemplos de mensagens POST comuns em servidores UEFI

Em ambientes de servidor, é comum encontrar erros relacionados ao IOH durante a última inicialização. Mensagens como “Erro incorrigível detectado na última inicialização: Erro de protocolo IOH(0)”, “Erro IOH(0) QPI [x]”, “Erro PCI-E [x]”, “Erro ESI”, “Erro térmico”, “Erro diverso” ou “Erro VT-d” indicam problemas detectados no concentrador de E/S ou nos links que ele gerencia.

Em todos esses casos, a recomendação típica é revisar a função de gerenciamento de falhas e o log de eventos do SP no Oracle ILOM ou em outro console equivalente para obter mais detalhes. Esses logs geralmente especificam se foi uma falha isolada, uma condição térmica, um erro de link QPI, um problema com uma porta PCIe específica ou um conflito com funções de virtualização de E/S (VT-d).

Outra mensagem comum é “Erro no disco rígido”, associada a falhas em unidades SAS ou SATA. O firmware geralmente indica que ocorreu um erro em uma unidade de disco e recomenda verificar o log do SP para identificar qual compartimento, porta ou LUN está causando o problema, bem como verificar o status dos discos no controlador correspondente.

Mensagens como “Assinatura PBR inválida” indicam problemas com a tabela de partições do disco. Nesses casos, a causa geralmente é uma tabela de partições ausente ou corrompida na unidade. A solução envolve recriar as tabelas de partições com as ferramentas apropriadas (por exemplo, os utilitários de formatação no Oracle Solaris ou o fdisk no Linux ) e reinstalar o sistema, se necessário.

O subsistema de memória exibe erros como “Teste de leitura/gravação da RAM falhou ”, indicando que o teste de leitura/gravação da RAM durante o POST falhou. Novamente, recomenda-se revisar o log de eventos do SP para localizar o banco ou módulo específico afetado e, em seguida, proceder com uma inspeção física dos módulos de memória (reinstalando-os, testando-os individualmente ou substituindo-os).

Avisos relacionados à bateria e à configuração da CMOS também são relativamente comuns , como “Bateria CMOS fraca” ou erros genéricos da CMOS. Essas mensagens indicam que a bateria que alimenta a memória CMOS — onde a hora, a data e algumas configurações são armazenadas — está descarregada ou com defeito, e que é recomendável verificar o suporte técnico e, geralmente, substituir a bateria.

Na seção de segurança, mensagens como “Falha na verificação de senha” aparecem quando a verificação da senha configurada no firmware falha. Em um ambiente gerenciado, esses eventos também são registrados no SP/IMM para rastrear tentativas malsucedidas de acesso à configuração do sistema.

Significado dos bipes POST no BIOS Award e AMI

Além dos códigos exibidos na tela ou registrados nos arquivos, muitas BIOS ainda utilizam padrões de bipes para indicar erros, o que é especialmente útil quando o sistema não consegue inicializar o vídeo. A combinação de bipes curtos e longos ajuda a identificar se o problema está na memória RAM, no processador, no teclado, na placa de vídeo ou na própria BIOS.

Em sistemas com BIOS Award moderna, os bipes geralmente indicam problemas de vídeo . Um bipe longo seguido de dois bipes curtos sugere um erro na placa gráfica ou em um dos dispositivos de vídeo; a recomendação é verificar se a placa está encaixada corretamente no slot (PCIe, AGP em sistemas mais antigos) e tentar outra, se possível. Outros padrões de bipes geralmente apontam para erros de memória.

A tabela de BIOS Award também detalha combinações como um bipe curto (inicialização correta), dois bipes curtos (problema na CMOS solucionável redefinindo a configuração removendo a bateria ou movendo o jumper apropriado), um bipe longo e um bipe curto (problemas na placa-mãe ou na RAM), um bipe longo e três bipes curtos (teclado) e assim por diante, com recomendações que variam desde a reinstalação de módulos até a substituição de componentes.

As BIOS AMI possuem uma tabela ligeiramente mais extensa de bipes numerados. Por exemplo, um bipe indica um erro de atualização de memória, dois um erro de paridade, três um problema nos primeiros 64 KB de RAM, quatro um temporizador do sistema não funcional, cinco um erro de processador, seis um erro na porta A20, oito erros de leitura/gravação na memória de vídeo, nove um checksum da ROM incorreto, dez um problema no registrador de fechamento da CMOS e onze uma falha de cache.

O procedimento costuma ser semelhante na maioria dos casos: reinstalar os módulos , testar com um componente diferente ou, se o problema estiver na placa-mãe ou na BIOS, enviar o equipamento para reparo ou atualizar o firmware. Muitos manuais também recomendam o uso de borrachas macias para limpar os contatos dos módulos de RAM ou placas de vídeo quando houver suspeita de mau contato devido a sujeira ou oxidação.

Na prática, é possível distinguir duas "famílias" de bipes facilmente reconhecíveis : bipes contínuos, sejam curtos ou longos e repetitivos, geralmente indicam problemas na memória RAM ou na fonte de alimentação; enquanto sequências melódicas não repetitivas tendem a apontar para falhas na placa gráfica ou em outros dispositivos específicos. Compreender esse padrão ajuda a identificar o componente suspeito.