Cómo interpretar errores durante el POST de UEFI y BIOS

Inicio » Hardware » Cómo interpretar errores durante el POST de UEFI y BIOS

Encender el ordenador y que no pase de la pantalla inicial, solo emita pitidos raros o se quede en negro es una de esas situaciones que ponen a prueba la paciencia de cualquiera. Detrás de ese comportamiento está el POST (Power-On Self Test) ejecutado por la BIOS o la UEFI, y aprender a interpretar sus errores es la diferencia entre ir a ciegas y saber exactamente por dónde empezar a revisar el hardware.

Durante el POST, el firmware del equipo recorre una secuencia de comprobaciones muy bien definida: valida el procesador, la memoria, los buses, los dispositivos de arranque, controladores, etc. Cuando algo falla, puede avisarte con mensajes en pantalla, códigos hexadecimales, LEDs o pitidos. Cada fabricante implementa sus propios códigos, así que no basta con oír “un pitido largo y dos cortos”; hay que saber qué BIOS/UEFI tienes y cómo mapea cada combinación a un fallo concreto.

Qué es el POST y por qué es tan importante en UEFI

El POST (Power-On Self Test) es la auto-prueba que ejecuta cualquier PC justo después de recibir energía. Históricamente fue estandarizado por IBM y hoy sigue la misma filosofía tanto en BIOS clásicas como en firmwares UEFI modernos: antes de que el sistema operativo tenga la más mínima oportunidad de arrancar, el firmware se asegura de que el hardware crítico está en condiciones mínimas de funcionamiento.

Este proceso vive en el propio firmware (BIOS/UEFI), no en el disco ni en el sistema operativo. Eso significa que se ejecuta aunque no tengas disco, ni Windows, ni Linux, ni nada instalado. El POST hace cosas como comprobar registros del procesador, verificar la integridad del propio código de la BIOS/UEFI, inicializar temporizadores, DMA, controladores de interrupciones, medir e inicializar la RAM y configurar los dispositivos esenciales para poder seguir arrancando.

La primera fase del POST se centra en el hardware primario: CPU, memoria, placa base, controladores fundamentales y, en muchos casos, la tarjeta gráfica básica necesaria para mostrar algo en pantalla. Una vez superada, suele venir una segunda oleada de comprobaciones donde se validan periféricos y dispositivos secundarios: unidades de almacenamiento, tarjetas plug-and-play, puertos serie o paralelo, ratón, teclado, unidades ópticas, etc.

Si alguna de esas comprobaciones falla de forma crítica, el POST detiene el arranque. Dependiendo del diseño del firmware y de la gravedad, el fallo puede ser “tolerable” (se muestra un aviso pero se permite continuar) o lo bastante serio como para que el sistema no pase de ahí. Ahí es donde entran en juego los códigos de error: sonidos, mensajes, valores hexadecimales o LEDs que indican en qué punto exacto ha tropezado la secuencia.

En el mundo UEFI, la filosofía es la misma, pero con más opciones de diagnóstico. Muchos servidores y placas de gama alta muestran códigos POST en displays de 7 segmentos, guardan registros detallados en controladoras de gestión (BMC, IMM, SP, ILOM) y permiten consultar el histórico de errores incluso si ya han pasado varios arranques desde el fallo original.

Cómo se generan y registran los códigos de error POST en UEFI

En plataformas modernas con UEFI, los códigos de error de diagnóstico pueden aparecer al arrancar o incluso con el servidor ya en marcha. Estos códigos no solo se muestran en pantalla o mediante pitidos; suelen registrarse también en el registro de sucesos del módulo de gestión, como el IMM de Lenovo o el Service Processor (SP) en servidores IBM y Oracle.

En estos equipos empresariales, cada evento POST o UEFI suele ir acompañado de una “Respuesta del usuario” recomendada. Este campo describe los pasos que el administrador debe seguir para intentar resolver el suceso: revisar registros, comprobar componentes, reiniciar el procesador de servicio, verificar fuentes de alimentación, etc. El flujo típico es claro: seguir las acciones en el orden indicado y, si después de completarlas el problema persiste, escalar el caso al soporte oficial del fabricante (IBM, Lenovo, Oracle, etc.).

Un ejemplo clásico en servidores IBM/Oracle son los errores de IOH (I/O Hub) detectados como “Uncorrectable Error Detected on Last Boot”. El mensaje puede detallar el tipo de fallo: error de protocolo, QPI, PCIe, ESI, térmico, varios (miscellaneous), VT-d, etc. Aunque al usuario solo le llega un texto genérico en el arranque, el detalle real está en el log del SP o en el Oracle ILOM, donde se almacenan los eventos con fecha, hora, severidad y contexto técnico.

Cuando aparece un error de IOH en estos entornos, el procedimiento recomendado suele ser revisar la función de gestión de fallos y el registro de eventos del SP. Ahí se puede ver si el problema es algo puntual (por ejemplo, un pico de temperatura o un error de enlace QPI aislado) o si estamos ante un fallo recurrente en un bus PCIe, en un enlace de memoria o en un componente físico que ya toca sustituir.

Otros mensajes UEFI/POST típicos en servidores de este tipo incluyen avisos de BMC que no responde, errores de disco duro, batería CMOS baja o problemas de contraseña. Mensajes como “BMC Not Responding”, “Hard disk error”, “Bad PBR sig”, “RAM R/W test failed”, “CMOS Battery Low” o “Password check failed” aparecen durante el arranque y, de nuevo, se complementan con información más detallada en el log de eventos del SP o en la interfaz de gestión remota (Oracle ILOM, Lenovo XClarity, IBM IMM, etc.).

Mensajes UEFI/POST típicos y su interpretación en servidores

En el entorno de servidores, muchos errores POST van asociados al subsistema de gestión y a eventos almacenados en el SP o IMM. Entender el texto que aparece en pantalla es solo la primera capa; lo verdaderamente útil es saber dónde ir a buscar el detalle para diagnosticar bien.

Los mensajes de error “Uncorrectable Error Detected on Last Boot: IOH(0) …” indican fallos graves en el hub de entrada/salida. Pueden referirse a errores de protocolo, problemas en enlaces QPI concretos, fallos en buses PCIe asociados, errores en el enlace ESI, incidencias térmicas o problemas relacionados con VT-d. Ante cualquiera de estos mensajes, lo prudente es:

• Acceder a Oracle ILOM (u otro gestor equivalente) y revisar la función de gestión de fallos, que suele señalar el componente o el bus implicado.
• Comprobar el registro de eventos del SP en busca de repeticiones del mismo error, degradaciones previas o correlaciones con otros eventos (por ejemplo, sobretemperatura).
• Valorar un reinicio del SP si el problema parece estar en la comunicación SP-BIOS más que en el hardware físico, sobre todo cuando hay mensajes del tipo “BMC Not Responding”.

El mensaje “BMC Not Responding (BMC no responde)” suele apuntar a un fallo interno en la comunicación entre el procesador de servicio y la BIOS. No siempre implica hardware roto; a menudo basta con reiniciar el SP o actualizar su firmware. No obstante, si el mensaje persiste tras reinicios y actualizaciones, puede ser síntoma de una placa base o un módulo BMC defectuoso.

Cuando el POST indica “Hard disk error” o “Bad PBR sig” estamos ante problemas en el subsistema de almacenamiento; conviene comprobar la salud del disco con herramientas que informen de velocidad, sectores defectuosos y SMART, ya que el log del SP suele aportar más contexto (número de bahía, ID de la controladora SAS, tipo de fallo, etc.). Mientras tanto, “Bad PBR sig” apunta a una tabla de particiones inexistente o dañada: se ha perdido la firma del PBR (Partition Boot Record) y el firmware no encuentra una estructura de arranque válida.

Errores como “RAM R/W test failed” o “Uncorrectable ECC Error” señalan fallos en la memoria, a menudo detectados por los mecanismos ECC; revisar los modos Gear y timings de memoria puede ayudar a diagnosticar incompatibilidades o configuraciones que disparan errores. De nuevo, el log del SP suele detallar banco, módulo o canal afectado, lo que permite actuar de forma precisa: retirar el DIMM conflictivo, reforzar la ventilación si hay correlación con temperaturas altas o actualizar el firmware de la controladora de memoria.

Los avisos relativos a CMOS, como “CMOS Battery Low” o “CMOS Checksum Invalid”, indican problemas con la batería o con los datos de configuración guardados. Una batería baja hace que el sistema pierda la hora, la fecha y, en ocasiones, parte de la configuración del firmware al apagar el equipo. Un checksum inválido sugiere corrupción en los datos almacenados, ya sea por batería agotada, por cambios bruscos de alimentación o por una operación de actualización incompleta.

Mensajes POST clásicos en BIOS AMI, Award y Phoenix

Más allá de UEFI y de los servidores de gama alta, siguen existiendo muchos equipos con BIOS “clásicas” (o con compatibilidad heredada) que muestran mensajes POST textuales cuando algo no va bien. Fabricantes como AMI, Award y Phoenix tienen su propio repertorio de mensajes que conviene conocer si te dedicas a reparar equipos o a diagnosticar fallos complejos.

En BIOS AMI, puedes encontrarte avisos relacionados con PnP, NVRAM, conflictos de recursos, controladores y discos de arranque. Algunos ejemplos típicos son:

• “Bad PnP Serial ID Checksum”: el checksum de la tarjeta PnP es inválido, lo que suele apuntar a un problema con la tarjeta o con la lectura de su información.
• “NVRAM Checksum Error – NVRAM Cleared” o “NVRAM Data Invalid – NVRAM Cleared”: se han detectado datos corruptos en la ESCD/NVRAM y el sistema los ha reinicializado, a menudo cargando valores por defecto.
• “PCI I/O Port Conflict”, “PCI IRQ Conflict” o “PCI Memory Conflict”: dos dispositivos pugnan por la misma dirección de E/S, la misma IRQ o el mismo rango de memoria; típicamente tarjetas mal configuradas o BIOS incapaces de negociar recursos automáticamente.
• “Primary Boot Device Not Found”: el dispositivo designado como primario de arranque no se localiza, puede ser por configuración de arranque errónea, cableado, o disco ausente.

Otros mensajes AMI giran en torno a batería CMOS, errores de checksum, incongruencias de tamaño de memoria o tipo de pantalla y fallos de controladores. Avisos como “CMOS Battery State Low”, “CMOS Checksum Invalid”, “CMOS Memory Size Mismatch”, “Diskette Boot Failure”, “HDD Controller Failure” o “Insert Bootable Media” ayudan a delimitar rápidamente si el problema está en la configuración, en los controladores, en el medio de arranque o en la propia unidad física.

En BIOS Award es habitual ver mensajes relacionados con errores de ROM, batería, memoria, teclado, controladores de disco y ausencia de medio arrancable. Por ejemplo:

• “BIOS ROM checksum error – System halted”: la suma de verificación de la ROM de BIOS es incorrecta, lo que sugiere BIOS corrupta o chip defectuoso.
• “CMOS checksum error – Defaults loaded”: la configuración de CMOS está dañada y se cargan valores de fábrica para permitir el arranque.
• “Floppy disk(s) fail” o “FLOPPY DISK CONTROLLER ERROR OR NO CONTROLLER PRESENT”: la BIOS no puede encontrar o inicializar la controladora o la unidad de disquete.
• “HARD DISK INSTALL FAILURE” o “Primary master hard disk fail”: indica problemas al inicializar el disco maestro primario o el controlador correspondiente.

Award también usa mensajes para alertar de cambios de hardware, como “DISPLAY TYPE HAS CHANGED SINCE LAST BOOT” o “MEMORY SIZE HAS CHANGED SINCE LAST BOOT”, que avisan de que se ha modificado la tarjeta de vídeo o la cantidad de RAM desde el último arranque. Otros textos como “PRESS A KEY TO REBOOT”, “PRESS F1 TO DISABLE NMI, F2 TO REBOOT” o “SYSTEM HALTED” marcan puntos en los que el usuario debe intervenir tras un fallo no recuperable.

Phoenix BIOS combina mensajes textuales con códigos de pitidos muy detallados. En su repertorio textual aparecen errores de unidad de disquete (“Diskette drive A error”), de memoria extendida (“Extended RAM failed at offset”), de discos fijos (“Fixed Disk n Failure”, “Fixed Disk Controller Failure”), de tipo de unidad mal definido (“Incorrect Drive A: type – run Setup”), de NVRAM, de teclado, de reloj en tiempo real (“Real-time clock error”), de paridad en bus de E/S (“Parity Check n”) y de sistema operativo no encontrado (“Operating system not found”).

En todos estos casos, la clave está en no interpretar los mensajes de forma aislada. Un “Operating system not found” puede ser un disco muerto, pero también una tabla de particiones borrada o un orden de arranque mal configurado. Un “CMOS checksum bad” puede deberse a una batería agotada o a un corte de corriente en pleno guardado de parámetros; conviene siempre revisar contexto, cambios recientes y resto de síntomas.

Códigos de pitidos: cómo “escuchar” los errores de BIOS/UEFI

Cuando la BIOS o la UEFI no puede mostrar nada útil en pantalla (por ejemplo, por fallo de la gráfica), recurre a un lenguaje muy primitivo pero efectivo: los códigos de pitidos. Se generan con un pequeño altavoz (speaker) conectado a la placa base y siguen patrones de pitidos cortos y largos que codifican el tipo de error.

Estos códigos no son universales: cada fabricante de BIOS/UEFI define su propio mapa de sonidos. AMI, Award/Phoenix, IBM, Dell, Apple, ASUS y otros proveedores tienen combinaciones propias. Por eso, antes de intentar descifrar una secuencia de pitidos, es imprescindible identificar qué firmware lleva tu placa, algo que puedes ver en el propio arranque, en la pantalla de configuración (F2, Supr, F1…) o desde el sistema operativo con herramientas como CPU-Z.

En AMI BIOS, los códigos de pitidos clásicos se basan en secuencias de “cortos” y “largos” para señalar fallos de RAM, paridad, teclado, vídeo, procesador, pila CMOS y caché. Por ejemplo:

• 1 pitido corto: fallo en el refresco de la DRAM.
• 2 pitidos cortos: error en el circuito de paridad.
• 3 pitidos cortos: fallo en los primeros 64 KB de RAM.
• 4 pitidos cortos: problema con el temporizador del sistema.
• 5 pitidos cortos: error en el procesador.
• 6 pitidos cortos: error en el controlador del teclado.
• 8 pitidos cortos: memoria de vídeo fallando en lectura/escritura.
• 9 pitidos cortos: fallo en el checksum de la ROM de BIOS/UEFI.
• 10 pitidos cortos: pila CMOS agotada o error en el registro de apagado.
• 11 pitidos cortos: fallo en la caché.
• 1 pitido largo y 3 cortos: error general de memoria.
• 1 pitido largo y 8 cortos: fallo en el test de vídeo/display.
• Patrón de sirena de dos tonos: problemas de voltaje o ventilador de CPU demasiado lento.

En Award/Phoenix (en su variante Award), la tabla de sonidos hace más hincapié en errores de vídeo, RAM y CPU. Encontrarás, por ejemplo:

• 1 pitido corto: POST correcto, sin errores detectados.
• 2 pitidos cortos: error no específico mostrado en pantalla.
• Pitido continuo o pitidos continuos cortos: problemas de alimentación, gráfica no detectada o RAM ausente.
• 1 pitido largo: fallo de memoria RAM.
• 1 largo y 2 cortos: error de vídeo (no se puede inicializar una pantalla).
• 1 largo y 3 cortos: problema con la gráfica o el teclado, según la versión.
• Secuencias de tonos altos y bajos: fallos en el procesador, a menudo por sobrecalentamiento.

IBM tiene su propio sistema de pitidos para sus BIOS. En muchos modelos, la ausencia total de pitidos indica un problema grave de alimentación o de placa base; un solo pitido corto suele significar que el test básico ha pasado sin errores; dos pitidos cortos apuntan a un error que se detalla en pantalla. Secuencias como pitido continuo o múltiples pitidos cortos continuos vuelven a señalar problemas de corriente o ausencia de tarjeta gráfica.

Los equipos Dell utilizan códigos sencillos basados en el número de pitidos repetidos:

• 1 pitido: corrupción o fallo en la ROM de BIOS/UEFI.
• 2 pitidos: memoria RAM no detectada.
• 3 pitidos: fallo en la placa base.
• 4 pitidos: error en la RAM.
• 5 pitidos: batería de la CMOS agotada.
• 6 pitidos: fallo en la tarjeta gráfica.
• 7 pitidos: problemas en la CPU.

Apple, como casi siempre, va por su cuenta con los códigos de sonido para Mac. En sistemas basados en Intel se apoya en firmware EFI modificado, y los tonos de aviso se han personalizado. Puedes encontrarte, por ejemplo, un tono con dos frecuencias distintas que señala problemas en la placa lógica, un pitido corto por error de vídeo o series de tonos altos (uno seguido de cuatro aún más altos) asociados a errores de memoria. En Apple Silicon la cosa se vuelve aún más opaca: usan un sistema de verificación propio y el detalle de sus pitidos es poco público.

Códigos POST numéricos, puertos y tarjetas de diagnóstico

Además de pitidos y mensajes de texto, muchos BIOS/UEFI emiten códigos POST numéricos en un puerto de E/S específico. Tradicionalmente, el puerto estándar ha sido el 80h, donde la BIOS va escribiendo valores hexadecimales de un byte que identifican cada etapa de la secuencia POST. Estos valores pueden capturarse con tarjetas de diagnóstico que se conectan a un bus PCI, PCIe, ISA u otro, y muestran el último código recibido en un display de 7 segmentos.

No todos los fabricantes usan el mismo puerto para estos códigos. Por ejemplo, algunos Compaq los envían al puerto 84h, ciertos IBM PS/2 utilizan 90h o 190h, máquinas con arquitectura EISA y BIOS Award pueden optar por 300h, y sistemas con arquitectura MCA llegar a usar 680h. Otros equipos, especialmente modelos antiguos de AT&T, Olivetti o NCR, redirigen los códigos al puerto de impresión (direcciones 3BC, 278h o 378h).

En la práctica, las tarjetas POST modernas soportan varios puertos y estándares a la vez. Su funcionamiento es sencillo: se pinchan en un slot disponible, se enciende el equipo y el display LED muestra los códigos a medida que el firmware los emite. Si el sistema se queda congelado en un valor concreto o se reinicia siempre al llegar a un mismo código, ya tienes una pista clara de en qué etapa está fallando.

Conviene aclarar un matiz conceptual: técnicamente, estos no son “códigos de error POST”, sino códigos de estado. El firmware va escribiendo un valor distinto cada vez que entra en una prueba específica de la secuencia; solo cuando la rutina se interrumpe y el equipo no puede seguir adelante se convierte en “código de error” a efectos prácticos. Esa distinción es académica, porque en la jerga se ha impuesto llamarles códigos de error POST, pero entenderla ayuda a interpretar correctamente lo que está pasando.

Otro detalle fino es el momento exacto en el que se detiene el firmware respecto al código mostrado. Algunos BIOS se paran después de escribir el código actual (es decir, el valor que ves es el de la prueba que está fallando); otros se detienen antes de actualizarlo (en cuyo caso el fallo real puede estar en el paso siguiente al código visible). Cuando un equipo insiste en quedarse clavado en el mismo valor pese a corregir lo que ese código sugiere, conviene revisar la documentación del fabricante para ver cómo maneja este timing.

Cómo saber si el POST ha fallado y por dónde empezar

Detectar que el POST ha fallado suele ser bastante directo, pero conviene fijarse en todos los síntomas. Los casos más comunes son:

• La pantalla se queda congelada con el logo de la placa base y no continúa el arranque.
• Aparece algo de texto o un logo y el equipo se apaga o reinicia solo en mitad de la rutina.
• Solo ves texto sobre fondo negro y nada parece avanzar, a veces acompañado de un mensaje breve de error.
• El equipo no muestra vídeo, pero emite pitidos repetitivos o se encienden LEDs de diagnóstico en la placa.

En muchas placas modernas ya no se incluye speaker, y el diagnóstico se apoya en LEDs o en displays de 7 segmentos con códigos hexadecimales. Algunos fabricantes añaden un pequeño display que muestra códigos (por ejemplo, “07”, “30”, “98”…), y otros usan bloques de LEDs etiquetados para CPU, DRAM, VGA y BOOT, donde cada color o parpadeo indica el componente que está dando guerra.

Un ejemplo simple: si el POST se detiene en un código que la tabla del BIOS describe como “Next, initializing the CPU and the CPU data area (07h)”, está bastante claro que el problema se centra en el procesador o en su entorno inmediato (socket, alimentación de CPU, circuitería asociada). Probar con otra CPU conocida en buen estado o inspeccionar el zócalo en busca de pines doblados, pistas dañadas o reguladores quemados es un paso lógico.

Otro ejemplo: si el código visible corresponde a “The adaptor ROM had control and has now returned control to BIOS POST (98h, según ciertas tablas de Award)”, la sospecha recae en alguna ROM de dispositivo opcional (por ejemplo, una tarjeta RAID, una controladora de red con ROM de arranque, etc.) o en la forma en que la BIOS recupera el control tras ejecutar esa ROM. Aquí puede ser necesario revisar qué tarjetas hay instaladas, actualizar su firmware o incluso estudiar el diagrama de la placa si se trata de un diagnóstico muy fino.

En placas con display de dos dígitos, el uso de tarjetas de diagnóstico PCI/PCIe puede complementar muy bien el análisis. Muchas de estas tarjetas soportan varios fabricantes de BIOS (AMI AptioV, Award, Phoenix, etc.), incluyen su propia tabla de interpretación y permiten ver no solo el último código, sino la secuencia de valores previos, lo que ayuda a entender hasta dónde llega el POST antes de morirse.

Errores POST y la realidad física de la placa base

Algo que se olvida con frecuencia es que la placa base no es solo “software” en forma de BIOS/UEFI y ROMs. Es un circuito electrónico complejo en el que fallan condensadores, resistencias, diodos, pistas, reguladores y chips de soporte. Muchos “errores raros” de POST que no encajan bien con lo aparente acaban estando relacionados con componentes pasivos fuera de rango, soldaduras frías o líneas dañadas.

Los fallos electrónicos de este tipo son especialmente traicioneros porque a veces se manifiestan solo en frío, solo en caliente o solo bajo ciertas cargas. Un condensador hinchado en la etapa de alimentación de la CPU puede permitir que el POST avance a veces y otras no; una resistencia abierta en el circuito del reloj puede causar errores intermitentes en temporizadores o en el RTC; un diodo defectuoso puede provocar caídas de tensión en un bus concreto.

Por eso, cuando los códigos POST apuntan a un área pero cambiar el componente sospechoso no resuelve el problema, hay que ampliar la mirada. Revisar visualmente la placa con buena iluminación, buscar condensadores abombados, zonas quemadas, óxido cerca de la batería CMOS o restos de líquido ayuda más de lo que parece. En entornos profesionales, tirar de osciloscopio, multímetro y diagramas de servicio es ya obligatorio.

En portátiles y equipos muy compactos, la dificultad aumenta porque muchos buses y señales internas no están accesibles. Además, algunos fabricantes ni siquiera usan el puerto estándar 80h para sus códigos POST o no exponen un slot donde pinchar una tarjeta de diagnóstico. En esos casos, los LEDs de diagnóstico y la documentación oficial del modelo son prácticamente la única pista para desentrañar errores de arranque complejos.

Al final, interpretar errores durante el POST de UEFI o BIOS es combinar la teoría de los códigos con una visión realista del hardware que tienes delante. Saber qué significa un pitido o un valor hexadecimal te acorta mucho el camino, pero la reparación real pasa por cables, módulos de RAM, tarjetas gráficas, discos, fuentes de alimentación y placas base que, a veces, simplemente han llegado al final de su vida útil.

Si dominas cómo funciona el POST, qué significan sus mensajes y dónde se registran los errores en firmwares UEFI modernos, pasarás de estar a oscuras cada vez que tu PC se queda mudo al arrancar a tener un mapa bastante preciso de por dónde empezar: revisar logs del SP o IMM, escuchar pitidos, leer códigos hexadecimales y, sobre todo, entender qué parte del hardware está levantando la mano para pedir atención.