Cómo diagnosticar y solucionar caídas de NVMe del bus PCIe (CSTS=0xffffffff, reset failure -19)

Problema

En entornos de virtualización o servidores de alta disponibilidad, es frecuente que el sistema de archivos raíz se vuelva de solo‑lectura y el host se quede colgado sin una causa evidente en los logs locales. Un patrón recurrente es la pérdida del controlador NVMe del bus PCIe, que se manifiesta con mensajes como:

nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10
nvme nvme0: Disabling device after reset failure: -19
EXT4-fs (dm-1): I/O error while writing superblock
EXT4-fs (dm-1): Remounting filesystem read-only

El controlador deja de responder, el kernel marca el dispositivo como fallido y el disco desaparece del árbol PCI. La situación ocurre tanto bajo carga intensiva como en reposo prolongado, y el único remedio suele ser un power‑cycle completo. El problema no está limitado a un modelo de SSD concreto, a una ranura M.2 específica ni a una versión de BIOS; es una falla que puede afectar cualquier combinación de hardware y firmware cuando el enlace PCIe se vuelve inestable.

Causa

Varias causas pueden desencadenar la condición CSTS=0xffffffff:

Problemas de gestión de energía en el enlace PCIe
- ASPM (Active State Power Management) o L1 Substates mal implementados pueden provocar que el controlador NVMe entre en un estado de bajo consumo del que no se recupera.
- APST (Autonomous Power State Transition) habilitado en el SSD también genera transiciones de latencia que el kernel no siempre maneja correctamente.
Firmware del SSD desincronizado con el controlador del chipset
- Versiones antiguas de firmware pueden contener bugs que hacen que el controlador responda con todos los bits a 1 al recibir un comando de reset.
- Algunas unidades NVMe utilizan un “vendor‑specific” power‑saving mode que el driver de Linux no detecta.
Inestabilidad del enlace físico
- Contacto imperfecto entre la placa base y la M.2, o trazas de señal que no cumplen con los requisitos de velocidad (PCIe 3.0 x4 vs. x2).
- Problemas de suministro eléctrico localizados: caída de tensión momentánea en el rail de 3.3 V que alimenta la SSD.
Configuración del BIOS/UEFI
- Opciones como “PCIe Native Power Management” o “Link State Power Management” que el kernel no puede desactivar automáticamente.
- Compatibilidad limitada con la generación de CPU/Chipset (por ejemplo, Z390 con dispositivos PCIe 4.0).
Interacción con capas de abstracción de almacenamiento
- LVM, dm‑crypt o ZFS pueden retrasar la detección del fallo, pero no evitan que el controlador se apague.
- Controladores de red o GPU que comparten el mismo root‑port pueden generar interferencias electromagnéticas bajo ciertas condiciones térmicas.

Solución

Una estrategia robusta combina ajustes de kernel, actualización de firmware y verificación física. Los pasos a seguir son los mismos tanto si el problema ocurre en Proxmox, Ubuntu Server o cualquier distro basada en Debian/Red Hat.

1. Desactivar todas las capas de ahorro de energía en PCIe y NVMe

Añade los siguientes parámetros al GRUB_CMDLINE_LINUX_DEFAULT y actualiza GRUB:

nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off

nvme_core.default_ps_max_latency_us=0 fuerza al driver a no entrar en estados de bajo consumo.
pcie_aspm=off desactiva ASPM a nivel de kernel.
pcie_port_pm=off evita que el controlador del puerto PCIe intente gestionar la energía de forma autónoma.

Después de editar /etc/default/grub, ejecuta:

update-grub && reboot

2. Verificar y actualizar el firmware del SSD

Descarga la última versión del firmware desde el sitio del fabricante. En la mayoría de los casos, el proceso se realiza mediante una herramienta bootable (por ejemplo, fwupd o el paquete nvme-cli):

nvme fw-download /dev/nvme0 --fw /ruta/al/firmware.bin
nvme fw-commit /dev/nvme0 --slot=1 --action=download

Reinicia y confirma la versión con nvme id-ctrl /dev/nvme0 | grep FR.

3. Forzar el enlace PCIe a la velocidad más baja y al ancho de banda máximo

En BIOS, fuerza el modo PCIe a Gen2 x4 o Gen3 x2. Si la BIOS no permite la selección, usa setpci para forzar la velocidad después del arranque:

setpci -s 0000:1d.0 CAP_EXP+0x10.w=0x0010   # ejemplo: fuerza a Gen2

Asegúrate de reemplazar 1d.0 por el BDF del controlador NVMe (lspci -nn | grep -i nvme).

4. Mejorar la alimentación eléctrica del slot M.2

Conecta el SSD a un rail de alimentación dedicado si la placa lo permite (algunas boards ofrecen “M.2 Power Switch”).
Verifica la tensión con un multímetro o con un osciloscopio; la caída no debe superar 0.1 V bajo carga.
Si la PSU tiene varios rails, prueba a mover el cable de alimentación principal a otro con mayor margen.

5. Reemplazar la ranura o el controlador PCH

En caso de que la inestabilidad persista, migra el SSD a una tarjeta de expansión PCIe x4 con su propio controlador NVMe (por ejemplo, un adaptador AOC‑SLV3). Esto elimina la posible interacción con el PCH y aísla el problema a la propia unidad.

6. Monitoreo continuo y fallback automático

Implementa un script de watchdog que detecte la desaparición del dispositivo y realice un reboot controlado antes de que el host quede inutilizable:

#!/bin/bash
DEV="/dev/nvme0n1"
while true; do
    if ! lsblk | grep -q "$DEV"; then
        logger "NVMe $DEV desapareció, reiniciando host"
        systemctl reboot
    fi
    sleep 30
done

Guárdalo en /usr/local/sbin/nvme-watchdog.sh, habilítalo como servicio y asegúrate de que el logger del sistema capture el evento.

Cuándo aplicar esta solución

Síntomas: pérdida del controlador NVMe, mensajes CSTS=0xffffffff, sistema de archivos se vuelve read‑only, reinicio necesario para recuperar el disco.
Entorno: servidores Linux con SSD NVMe como disco de arranque, especialmente bajo Proxmox, ESXi o cualquier hipervisor que use LVM/dm‑crypt.
No aplica: fallos que aparecen exclusivamente bajo carga de escritura intensiva y que se acompañan de errores de media (SMART) o de temperatura crítica; en esos casos el SSD está físicamente dañado y la sustitución es la única solución viable.

Código

# 1. Añadir parámetros de kernel
sed -i 's/^GRUB_CMDLINE_LINUX_DEFAULT="/GRUB_CMDLINE_LINUX_DEFAULT="nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off /' /etc/default/grub
update-grub

# 2. Actualizar firmware NVMe
nvme fw-download /dev/nvme0 --fw /tmp/firmware.bin
nvme fw-commit /dev/nvme0 --slot=1 --action=download

# 3. Forzar velocidad PCIe (ejemplo BDF 0000:1d.0)
setpci -s 0000:1d.0 CAP_EXP+0x10.w=0x0010

# 4. Instalar watchdog
cat > /usr/local/sbin/nvme-watchdog.sh <<'EOF'
#!/bin/bash
DEV="/dev/nvme0n1"
while true; do
    if ! lsblk | grep -q "$DEV"; then
        logger "NVMe $DEV desapareció, reiniciando host"
        systemctl reboot
    fi
    sleep 30
done
EOF
chmod +x /usr/local/sbin/nvme-watchdog.sh
cat > /etc/systemd/system/nvme-watchdog.service <<'EOF'
[Unit]
Description=Watchdog para detección de caída de NVMe

[Service]
ExecStart=/usr/local/sbin/nvme-watchdog.sh
Restart=always

[Install]
WantedBy=multi-user.target
EOF
systemctl enable --now nvme-watchdog.service

Verificación

Reproducir el fallo: deja el host en funcionamiento durante varias horas y observa si el mensaje CSTS=0xffffffff vuelve a aparecer.
Comprobar parámetros activos: cat /proc/cmdline debe contener los tres flags de energía.
Validar firmware: nvme id-ctrl /dev/nvme0 | grep FR muestra la versión esperada.
Confirmar enlace PCIe: lspci -vv -s 0000:1d.0 | grep LnkCap y LnkSta deben coincidir con la velocidad forzada.
Test de alimentación: usa ipmitool sensor get "Voltage 3.3V" (si el servidor tiene IPMI) para asegurarte de que la tensión se mantiene estable.
Watchdog: desconecta temporalmente el SSD (por ejemplo, con echo 1 > /sys/bus/pci/devices/0000:1d.0/remove) y verifica que el servicio genera el log y ejecuta el reboot.

Notas adicionales

En placas con BIOS muy antiguas, los ajustes de ASPM pueden no persistir después de un cold‑reset; siempre revisa que la configuración se mantenga tras un power‑cycle.
Algunas unidades Samsung incluyen un “Power Loss Protection” que se desactiva cuando el controlador PCIe entra en estado L1; desactivar L1 mediante pcie_aspm=off suele evitar el problema.
Si el servidor está bajo

Problema#

Causa#

Solución#

1. Desactivar todas las capas de ahorro de energía en PCIe y NVMe#

2. Verificar y actualizar el firmware del SSD#

3. Forzar el enlace PCIe a la velocidad más baja y al ancho de banda máximo#

4. Mejorar la alimentación eléctrica del slot M.2#

5. Reemplazar la ranura o el controlador PCH#

6. Monitoreo continuo y fallback automático#

Cuándo aplicar esta solución#

Código#

Verificación#

Notas adicionales#

Si te interesa esto, también revisa...