Ubuntu 24.04: NVMe desaparece bajo carga — los ajustes de energía/ASPM que suelen solucionarlo

Estás empujando I/O — punto de control de base de datos, ventana de copia de seguridad, granja de compilación, lo que sea — y de pronto el NVMe simplemente… se va.
Un momento está como /dev/nvme0n1, al siguiente es un misterio arqueológico. Tu sistema de archivos pasa a solo lectura, tu RAID/ZFS alarma,
y tu monitorización se ilumina como un árbol de Navidad que no pediste.

En Ubuntu 24.04, ese patrón de “NVMe desaparece bajo carga” a menudo no significa que el SSD esté muriendo. Es gestión de energía: ASPM en el enlace PCIe
y/o APST dentro del controlador NVMe. Ambos pueden ser correctos en teoría y catastróficos en la práctica cuando el firmware de la plataforma, la topología PCIe
o el firmware del disco se ponen creativos. Aquí tienes la forma pragmática y adecuada para producción de diagnosticar rápido, arreglar con seguridad y demostrar que realmente lo arreglaste.

Qué significa realmente “NVMe desaparece” (y por qué rara vez es magia)

Cuando los operadores dicen “el NVMe desapareció”, normalmente se refieren a una de tres cosas:

1. El dispositivo de bloques desaparece:
   /dev/nvme0n1 desaparece, udev lo elimina y cualquier cosa montada en él es ahora un mal día.
2. El dispositivo permanece, pero el I/O se bloquea:
   sigue listado, pero las lecturas/escrituras se cuelgan, agotan el tiempo y luego el kernel escala a reiniciar el controlador.
3. La función PCIe deja de responder:
   el controlador NVMe está presente en el bus, pero el enlace hace flap o AER (Advanced Error Reporting) está avisando.

“Bajo carga” es la pista clave. Colas altas, escrituras sostenidas, DMA intenso y estrés térmico amplifican las sensibilidades de temporización.
Ahí es cuando las transiciones de estado de energía que “normalmente funcionan” empiezan a perder carreras.

Si esto ocurre en Ubuntu 24.04, probablemente estés en un kernel y stack NVMe relativamente moderno. Eso es bueno por las funciones.
También es bueno para descubrir que la gestión de energía de tu plataforma fue diseñada por un comité cuya responsabilidad terminaba en “arranca Windows”.

Hechos y contexto histórico que explican el lío

• ASPM precede a NVMe: PCIe Active State Power Management fue diseñado para ahorrar energía del enlace mucho antes de que NVMe se convirtiera en el estándar de almacenamiento.
• APST de NVMe existe porque importaba el consumo en reposo: Autonomous Power State Transitions se creó para permitir que los controladores ahorren energía sin intervención constante del SO.
• AER se volvió común a medida que PCIe aceleró: velocidades de enlace mayores y márgenes más ajustados hicieron que el reporte y la recuperación de errores fueran más críticos — y más visibles en logs.
• El firmware de NVMe de consumo a menudo optimiza para benchmarks: el rendimiento instantáneo puede ocultar casos límite desagradables bajo cargas sostenidas y mixtas.
• Los portátiles impulsaron valores agresivos de energía: muchos proveedores de plataforma priorizan la duración de batería, a veces enviando firmware “optimista” respecto a la estabilidad del enlace.
• Linux mejoró el runtime PM con el tiempo: pero “mejor” también significa “más activo”, lo que aumenta las probabilidades de golpear bugs específicos de la plataforma.
• PCIe Gen4/Gen5 hizo la integridad de señal menos indulgente: cuanto más rápido vas, más un trazado marginal o un retimer puede aparecer como “dispositivo que se cae al azar”.
• NVMe tiene múltiples capas de timeout: timeouts del controlador, timeouts de blk-mq, de sistema de archivos y reintentos a niveles superiores pueden enmascarar el punto real de fallo.
• Ubuntu 24.04 ejecuta systemd con herramientas de energía agresivas disponibles: el espacio de usuario puede influir en runtime PM y la política, lo que a veces “ayuda” hasta que perjudica.

La conclusión operativa: tratas con una pila de energía en capas (firmware de plataforma, política de enlace PCIe, política del controlador NVMe, runtime PM en Linux).
Si una capa miente, las demás la creen cortésmente — hasta que tu SSD te abandona en medio de un checkpoint.

Guía rápida de diagnóstico (revisa 1–2–3)

Cuando estás de guardia, no tienes tiempo para danzas interpretativas. Haz esto en orden.

1) Confirma que realmente es un problema de dispositivo/enlace, no una ilusión del sistema de archivos

• Busca timeouts nvme y reinicios de controlador en el log del kernel.
• Busca errores AER de PCIe desde el puerto ascendente (pcieport).
• Confirma si el dispositivo de namespace desapareció o simplemente quedó bloqueado.

2) Identifica las funciones de energía en juego

• ¿Está ASPM de PCIe habilitado en el sistema?
• ¿Está APST de NVMe habilitado (y cuáles son las latencias ociosas)?
• ¿Está el runtime PM configurado en auto para el dispositivo PCI NVMe?

3) Reproduce de forma segura y decide: estabiliza primero, optimiza después

• Ejecuta una carga de I/O controlada y observa patrones de error.
• Aplica el cambio estabilizador más pequeño (a menudo deshabilitar ASPM y/o APST).
• Vuelve a ejecutar la misma carga y compara logs, no sensaciones.

Idea parafraseada de Werner Vogels (fiabilidad/operaciones): “Todo falla; diseña para que la falla sea esperada y la recuperación, rutinaria.”

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las tareas que realmente ejecuto cuando un NVMe se comporta mal bajo carga. Cada una incluye (a) el comando, (b) qué significa típicamente la salida,
y (c) la decisión que tomas a partir de ello.

Tarea 1: Encontrar errores del kernel relacionados con NVMe rápidamente

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'nvme|pcie|aer|timeout|reset' | tail -n 60
Dec 29 09:11:22 server kernel: nvme nvme0: I/O 123 QID 6 timeout, aborting
Dec 29 09:11:22 server kernel: nvme nvme0: Abort status: 0x371
Dec 29 09:11:22 server kernel: nvme nvme0: controller is down; will reset: CSTS=0x1
Dec 29 09:11:23 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: 0000:02:00.0
Dec 29 09:11:23 server kernel: pcieport 0000:00:1c.0: AER: device recovery successful

Qué significa: Timeouts de I/O NVMe más reinicios de controlador a menudo indican inestabilidad del enlace/energía o bloqueos de firmware/controlador bajo carga.
Errores AER corregidos en el puerto ascendente son una pista sólida de que el enlace PCIe está teniendo fallos.

Decisión: Si ves timeouts/reinicios con ruido AER, prioriza cambios en ASPM/poder del enlace antes de culpar al sistema de archivos.

Tarea 2: Comprueba si el dispositivo namespace NVMe realmente desapareció

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MODEL,SERIAL,MOUNTPOINTS | egrep -i 'nvme|NAME'
NAME        TYPE   SIZE MODEL               SERIAL            MOUNTPOINTS
nvme0n1     disk 931.5G ExampleNVMe 1TB     ABCD1234
├─nvme0n1p1 part   512M                                     /boot
└─nvme0n1p2 part   931G                                     /

Qué significa: Si nvme0n1 desaparece aquí después del incidente, udev lo eliminó porque el controlador cayó del bus o falló gravemente.
Si permanece presente pero el I/O se cuelga, el controlador podría estar bloqueado pero todavía enumerado.

Decisión: “Desapareció de lsblk” te empuja hacia problemas de PCIe/enlace/energía o reinicios completos del controlador; “presente pero atascado” aún puede ser por energía, firmware o térmico.

Tarea 3: Inspeccionar el estado del controlador NVMe con nvme-cli

cr0x@server:~$ sudo nvme list
Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1      ABCD1234             ExampleNVMe 1TB                           1         120.0  GB /  1.00  TB    512   B +  0 B   3B2QEXM7

Qué significa: Si nvme list falla intermitentemente o no muestra dispositivos cuando ocurre el problema, el controlador está cayendo.

Decisión: Si el controlador cae, enfócate primero en la gestión de energía PCIe y el firmware de plataforma; SMART no te salvará si el bus desaparece.

Tarea 4: Extraer SMART/health y distinguir síntomas de medio frente a transporte

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 54 C
available_spare                     : 100%
percentage_used                     : 2%
media_errors                        : 0
num_err_log_entries                 : 18
power_cycles                        : 23
power_on_hours                      : 410
unsafe_shutdowns                    : 6

Qué significa: Errores de medio en cero con entradas de log de errores incrementándose a menudo apunta lejos de fallo de NAND y hacia reinicios de transporte/controlador.
El aumento de apagados no seguros es consistente con eventos de “controlador desapareció”.

Decisión: Si los errores de medio son bajos/cero pero los reinicios/timeouts son comunes, no pidas RMA de inmediato; estabiliza el comportamiento de energía/enlace y vuelve a probar.

Tarea 5: Leer el registro de errores NVMe para confirmar patrones de timeout/reinicio

cr0x@server:~$ sudo nvme error-log /dev/nvme0 | head -n 20
Error Log Entries for device:nvme0 entries:64
Entry[ 0]
 error_count     : 18
 sqid            : 6
 cmdid           : 0x00a2
 status_field    : 0x4004
 parm_error_location: 0x0000
 lba             : 0
 nsid            : 1
 vs              : 0x00000000

Qué significa: Errores repetidos en la misma cola bajo carga pueden alinearse con reinicios de controlador y abortos de comando. Generalmente es “el controlador se mosqueó”, no “los bits están malos”.

Decisión: Correlaciona los saltos en error_count con reinicios del kernel. Si coinciden, trátalo como un problema de estabilidad/estados de energía.

Tarea 6: Identificar la ruta del dispositivo PCIe (para inspeccionar el puerto ascendente)

cr0x@server:~$ sudo lspci -nn | egrep -i 'non-volatile|nvme'
02:00.0 Non-Volatile memory controller [0108]: Example Corp NVMe Controller [1234:11aa] (rev 01)

Qué significa: Tu controlador NVMe está en 0000:02:00.0. Esa dirección será tu ancla para AER, ASPM, runtime PM y estado del enlace.

Decisión: Usa ese BDF para consultar lspci -vv, sysfs power control y para localizar el puerto ascendente que podría generar AER.

Tarea 7: Comprobar estado del enlace PCIe y estado ASPM

cr0x@server:~$ sudo lspci -s 02:00.0 -vv | egrep -i 'LnkCap:|LnkSta:|ASPM|L1Sub|AER' -n
45:        LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us
52:        LnkSta: Speed 16GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
60:        L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+

Qué significa: Si LnkCap y líneas relacionadas muestran modos ASPM soportados/habilitados, el enlace puede entrar en estados de baja potencia.
Eso no es inherentemente malo, pero es un sospechoso principal cuando los dispositivos desaparecen bajo carga o durante tráfico con ráfagas.

Decisión: Si tienes dropouts y ASPM está habilitado, testar con ASPM deshabilitado suele valer la pena. Estabiliza primero.

Tarea 8: Confirma si el kernel piensa que ASPM está habilitado globalmente

cr0x@server:~$ cat /sys/module/pcie_aspm/parameters/policy
default

Qué significa: Políticas como default, powersave o performance influyen cuán agresivamente se usa ASPM.
Algunos sistemas funcionan de forma estable con default; otros lo tratan como una sugerencia para comportarse mal.

Decisión: Si persigues desapariciones, planifica un arranque de prueba con pcie_aspm=off. Si la estabilidad vuelve, has encontrado al culpable.

Tarea 9: Comprobar estado APST de NVMe (transiciones autónomas de energía del controlador)

cr0x@server:~$ cat /sys/module/nvme_core/parameters/default_ps_max_latency_us
0

Qué significa: Un valor de 0 típicamente significa “sin límite”, lo que permite estados de energía más profundos si el controlador/firmware los desea.
En algunos discos, las transiciones de inactividad profunda pueden interactuar mal con ráfagas y reinicios.

Decisión: Para pruebas de estabilidad, establece una latencia máxima conservadora (o deshabilita APST) usando un parámetro del kernel. No adivines; prueba.

Tarea 10: Inspeccionar el estado de runtime power management para la función PCI NVMe

cr0x@server:~$ cat /sys/bus/pci/devices/0000:02:00.0/power/control
auto

Qué significa: auto permite al kernel suspender en tiempo de ejecución el dispositivo cuando cree que está inactivo.
En plataformas inestables, el runtime PM puede ser el empujón extra que desencadena rarezas de enlace/controlador.

Decisión: Si ves reinicios, prueba forzando runtime PM a on (sin autosuspend) para el dispositivo NVMe.

Tarea 11: Comprobar timeouts NVMe configurados por el kernel

cr0x@server:~$ cat /sys/module/nvme_core/parameters/io_timeout
30

Qué significa: Ese es el timeout de I/O en segundos. Incrementarlo puede enmascarar síntomas (esperarás “más tiempo” antes del reinicio),
pero no arregla la causa si el controlador se está cayendo.

Decisión: No “arregles” desapariciones inflando timeouts a menos que sepas que el dispositivo está solo lento por GC interno. Las desapariciones no son problemas de latencia.

Tarea 12: Hacer una prueba de esfuerzo I/O que reproduzca el problema sin destrozar producción

cr0x@server:~$ sudo fio --name=nvme-load --filename=/dev/nvme0n1 --direct=1 --rw=randwrite --bs=4k --iodepth=64 --numjobs=4 --runtime=120 --time_based=1 --group_reporting
nvme-load: (groupid=0, jobs=4): err= 0: pid=9123: Mon Dec 29 09:15:01 2025
  write: IOPS=82.1k, BW=321MiB/s (337MB/s)(38.6GiB/123002msec)
    lat (usec): min=48, max=21234, avg=311.42, stdev=145.11

Qué significa: Quieres una carga reproducible que desencadene el problema. Si el dispositivo desaparece durante esta prueba, tienes un caso reproducible.
Si solo desaparece bajo un patrón mixto de lectura/escritura o secuencial, ajusta en consecuencia.

Decisión: Nunca ajustes la gestión de energía a ciegas. Reproduce, cambia una variable, vuelve a ejecutar y compara logs.

Tarea 13: Vigilar eventos AER en vivo mientras estresas

cr0x@server:~$ sudo dmesg -wT | egrep -i 'aer|pcieport|nvme|timeout|reset'
[Mon Dec 29 09:16:22 2025] pcieport 0000:00:1c.0: AER: Corrected error received: 0000:02:00.0
[Mon Dec 29 09:16:22 2025] nvme nvme0: I/O 87 QID 3 timeout, aborting
[Mon Dec 29 09:16:23 2025] nvme nvme0: controller is down; will reset: CSTS=0x1

Qué significa: La secuencia “AER corrected error” → “NVMe timeout” → “controller reset” es un argumento familiar.

Decisión: Trata AER como evidencia. Si deshabilitar ASPM detiene el spam de AER y los timeouts, probablemente hayas solucionado la causa raíz.

Tarea 14: Comprobar errores del puerto PCIe ascendente (no solo el endpoint NVMe)

cr0x@server:~$ sudo lspci -s 00:1c.0 -vv | egrep -i 'AER|UESta|CESta|Err' -n
78:        Capabilities: [100 v2] Advanced Error Reporting
96:        UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
104:       CESta:  RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-

Qué significa: Errores corregidos como RxErr+ indican problemas de señal a nivel de enlace o estados de energía marginales.
Son “corregidos” hasta que dejan de serlo.

Decisión: Si los errores corregidos se disparan bajo carga, deja de perseguir ajustes de sistema de archivos. Ve tras la gestión de energía del enlace y la estabilidad de la plataforma.

Tarea 15: Verificar que la unidad no esté sufriendo throttling térmico hasta la inestabilidad

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep -i 'temperature|warning|critical'
temperature                         : 73 C
critical_warning                    : 0x00

Qué significa: La temperatura por sí sola no prueba causalidad, pero “desaparece bajo carga” más temperaturas altas puede empujar controladores marginales más allá del límite.

Decisión: Si las temperaturas son altas, mejora la refrigeración y vuelve a probar antes de empezar a reescribir parámetros de inicio. La realidad del hardware vence al optimismo del software.

Pila de energía: ASPM vs APST vs runtime PM (quién puede dejar tu disco offline)

Hay tres perillas que la gente confunde. No lo hagas. Son capas diferentes y puedes cambiarlas independientemente.

ASPM de PCIe (ahorro de energía a nivel de enlace)

ASPM controla los estados de baja potencia del enlace PCIe (no los estados internos del controlador NVMe). Los principales actores:
L0s y L1 (y subestados L1 como L1.1/L1.2 en plataformas más nuevas).

En un mundo perfecto, el endpoint y el root port negocian, entran en estados de baja potencia cuando están inactivos y salen rápidamente cuando el tráfico se reanuda.
En el mundo en el que vivimos, las promesas de latencia de salida a veces son… aspiracionales. Bajo carga, puedes obtener transiciones en momentos incómodos:
I/O con ráfagas, interrupciones MSI/MSI-X, eventos de power gating y el ocasional bug de firmware que dice “sí, estoy despierto” cuando en realidad no lo está.

APST de NVMe (estados autónomos de energía del controlador)

APST es interno al controlador NVMe. Puede decidir entrar en estados de mayor ahorro cuando está inactivo, guiado por la política del SO (latencia máxima)
y las propias tablas del disco. Si el firmware del disco es quisquilloso, APST puede convertir “inactivo luego ocupado” en “inactivo luego reinicio del controlador”.

APST es también donde las “soluciones” se vuelven peligrosamente populares. La gente lo desactiva y el problema desaparece. Genial.
Luego despliegan esa configuración por todas partes y se preguntan por qué los portátiles pierden una hora de batería. Las decisiones en producción tienen consecuencias.

Runtime PM / autosuspend (ahorro de energía a nivel de dispositivo en el SO)

Runtime PM es el kernel decidiendo “este dispositivo está inactivo, suspendámoslo”. Para dispositivos PCI, eso puede implicar estados D y cambios de enlace.
Es un multiplicador: incluso si ASPM y APST están bien, el runtime PM puede desencadenar más transiciones.

Un chiste corto, prometido y relevante: la gestión de energía PCIe es como una luz con sensor de movimiento en un pasillo — genial hasta que llevas algo frágil y se apaga a mitad de camino.

Arreglos que suelen funcionar: parámetros del kernel, udev y opciones de BIOS

La estrategia ganadora es obtener primero estabilidad con el cambio menos invasivo, y luego reintroducir los ahorros de energía con cuidado.
No empieces por deshabilitar todo para siempre a menos que disfrutes teniendo que explicar el aumento del consumo a finanzas.

Opción de arreglo A: Deshabilitar ASPM de PCIe (alta tasa de éxito para “desaparece bajo carga”)

Esto es el instrumento contundente. A menudo funciona porque elimina por completo la ruta de transición de estado del enlace.
Puede aumentar un poco el consumo en reposo, dependiendo de la plataforma.

Prueba temporal (un arranque)

En el menú de GRUB, edita la línea de arranque y añade:
pcie_aspm=off

Cambio persistente (GRUB)

cr0x@server:~$ sudo sed -i 's/^GRUB_CMDLINE_LINUX_DEFAULT="/GRUB_CMDLINE_LINUX_DEFAULT="pcie_aspm=off /' /etc/default/grub
cr0x@server:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-xx-generic
Found initrd image: /boot/initrd.img-6.8.0-xx-generic
done

Qué significa la salida: update-grub regeneró la configuración de arranque y encontró tu kernel/initrd.

Decisión: Reinicia con la nueva línea del kernel. Vuelve a ejecutar tu reproducer (fio + vigilancia de dmesg). Si los dropouts se detienen, mantenlo mientras decides si quieres un cambio más específico.

Opción de arreglo B: Limitar o deshabilitar APST de NVMe (a menudo arregla “timeouts luego reinicio”)

Si el controlador está entrando en estados internos profundos de NVMe y no vuelve limpiamente, APST es la palanca.
En Linux, el control común es nvme_core.default_ps_max_latency_us=.

Configuraciones comunes

• Deshabilitar APST (a menudo): nvme_core.default_ps_max_latency_us=0 a veces se interpreta como “sin límite” en lugar de “deshabilitar”, según el comportamiento del kernel y las tablas del disco. En la práctica, muchos operadores usan un valor pequeño distinto de cero para evitar estados profundos.
• Evitar estados profundos: establecer una latencia máxima baja, como 1000 (1ms) o 5000 (5ms), para evitar las dormidas más profundas mientras aún se permiten ahorros moderados.

La verdad molesta: el número correcto depende de la plataforma y del disco. No es filosofía. Eso es lo que te dirán tus logs tras pruebas controladas.

Cambio persistente (GRUB)

cr0x@server:~$ sudo sed -i 's/^GRUB_CMDLINE_LINUX_DEFAULT="/GRUB_CMDLINE_LINUX_DEFAULT="nvme_core.default_ps_max_latency_us=5000 /' /etc/default/grub
cr0x@server:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-xx-generic
Found initrd image: /boot/initrd.img-6.8.0-xx-generic
done

Decisión: Si deshabilitar ASPM lo arregla, puede que no necesites ajustar APST. Si los cambios en ASPM no ayudan, APST es tu siguiente sospechoso. No cambies ambos a la vez a menos que solo busques detener la hemorragia y luego aislarás después.

Opción de arreglo C: Deshabilitar autosuspend en runtime para el dispositivo PCI NVMe

Para sistemas donde el runtime PM es demasiado listo, forzar que la función PCI del NVMe permanezca “on” puede ayudar.
Esto es una solución por dispositivo, así no castigas toda la máquina.

Inmediato (hasta reinicio)

cr0x@server:~$ echo on | sudo tee /sys/bus/pci/devices/0000:02:00.0/power/control
on

Qué significa: El dispositivo queda excluido del autosuspend en runtime.

Decisión: Si la estabilidad mejora, hazlo persistente con una regla udev.

Permanente vía regla udev

cr0x@server:~$ sudo tee /etc/udev/rules.d/80-nvme-runtimepm.rules >/dev/null <<'EOF'
ACTION=="add", SUBSYSTEM=="pci", KERNELS=="0000:02:00.0", ATTR{power/control}="on"
EOF
cr0x@server:~$ sudo udevadm control --reload-rules
cr0x@server:~$ sudo udevadm trigger -s pci

Qué significa la salida: No tener salida está bien; las reglas udev se recargaron y se reaplicaron. Verifica con la lectura de sysfs.

cr0x@server:~$ cat /sys/bus/pci/devices/0000:02:00.0/power/control
on

Decisión: Mantén esto si resuelve el problema y puedes tolerar la compensación de consumo. A menudo es menos intrusivo que deshabilitar ASPM globalmente.

Opción de arreglo D: Configuración BIOS/UEFI (cuando las perillas de software no bastan)

Si la causa raíz es el comportamiento ASPM a nivel de firmware o un problema de señal del diseño de placa, el software solo puede hacer hasta cierto punto.
Ajustes útiles en BIOS/UEFI incluyen:

• ASPM de PCIe: deshabilitar o poner en “off”. Algunos proveedores lo ocultan bajo “Power” o “Advanced > PCIe.”
• Native ASPM: apagarlo puede forzar comportamiento gestionado por firmware; encenderlo puede dejar que el SO lo controle. Qué ayuda depende de la calidad del proveedor. Sí, esa frase es molesta.
• Velocidad de enlace PCIe: forzar Gen3 en lugar de Gen4 puede estabilizar enlaces marginales. Este es el movimiento de “lo necesito estable hoy”.
• C-states globales / Package C-states: estados profundos de sueño de CPU pueden interactuar con power gating del chipset. Deshabilitar los estados más profundos a veces arregla.

Si acabas forzando Gen3 o deshabilitando C-states profundos para mantener el almacenamiento en línea, trátalo como un defecto de hardware/firmware que estás evitando, no como “tuning de Linux”.

Opción de arreglo E: Actualizaciones de firmware (NVMe + BIOS)

Actualizaciones de firmware NVMe pueden arreglar tablas APST, recuperación de reinicios y bugs de estados de energía. Actualizaciones de BIOS pueden arreglar entrenamiento PCIe y política ASPM.
Aplícalas como un adulto: control de cambios, ventana de mantenimiento y opciones de rollback verificadas cuando sea posible.

Tres micro-historias del mundo corporativo (porque la realidad es rara)

Micro-historia 1: El incidente causado por una suposición errónea

Un equipo manejaba una pequeña flota de hosts Ubuntu que ingerían logs en una cola local respaldada por NVMe. Los hosts estuvieron bien durante semanas.
Entonces una nueva versión de pipeline aumentó la concurrencia de escrituras en ráfaga. Al principio pareció software: corrupción de cola, reintentos extraños y picos repentinos de latencia.

La suposición errónea fue sutil: “Si SMART está limpio, el disco está bien.” Sus comprobaciones SMART no mostraban errores de medio y el spare parecía decente.
Entonces empezaron a ajustar la aplicación, ampliar buffers y añadir reintentos. Redujo errores visibles pero aumentó el tiempo de recuperación tras un stall.

Durante una ráfaga intensa, el kernel registró timeouts I/O NVMe, luego un reinicio del controlador y después el namespace desapareció. El gestor de procesos reinició servicios, lo que no ayudó.
Los hosts volvieron solo tras un reboot. El almacenamiento “se arregló solo”, y así sabes que volverá a suceder.

El modo real de fallo no era desgaste de NAND. Era inestabilidad del enlace PCIe bajo una gestión de energía agresiva en esa revisión de placa madre.
Deshabilitar ASPM detuvo el acto de desaparición de inmediato. El equipo luego probó reactivar ASPM pero limitando las latencias APST de NVMe. Eso funcionó en algunas máquinas, no en todas.

La lección operativa que anotaron: SMART te dice sobre la flash y salud del controlador, no si el enlace PCIe está teniendo un ataque de pánico.
Añadieron patrones de AER y reinicios NVMe a la alertas, para que la próxima vez lo detectaran antes de que el sistema de archivos pasara a solo lectura.

Micro-historia 2: La optimización que salió mal

Otra organización intentó reducir consumo en un clúster de laboratorio que “podría volverse producción”. Habilitaron un perfil de energía agresivo y
configuraron políticas del kernel para ahorrar energía. Las máquinas estaban mayormente inactivas, con trabajos de compilación pesados periódicos.

En papel era sensato: máquinas inactivas deberían consumir poco. En la práctica, el clúster empezó a perder dispositivos NVMe durante las ráfagas de compilación.
El patrón era enloquecedor: largo reposo, luego tormenta de compilación, luego reinicio del controlador a mitad de escritura de artefactos.

Perseguían el rendimiento durante semanas. No era el throughput; era un problema de transición de estado. La carga de compilación tenía comportamiento on/off agudo:
nada por minutos, luego churn extremo de metadata y escrituras paralelas. Básicamente una prueba de tortura para estados de energía.

La “optimización” era runtime PM + ASPM profundo + APST permisivo. Hizo que la plataforma entrara constantemente en estados de sueño profundo,
luego exigiera wakeups instantáneos en el peor momento. Deshabilitar el autosuspend runtime para el dispositivo NVMe arregló la mayoría de los nodos.
Los pocos restantes necesitaron ASPM off.

Lo interesante: una vez estables, reintrodujeron ahorro de energía con cuidado — una perilla a la vez, validada con la misma carga.
Los objetivos de consumo se cumplieron en gran medida sin sacrificar la confiabilidad del almacenamiento, pero solo después de dejar de tratar la configuración de energía como inofensiva.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Un servicio financiero corría en un par de cajas de base de datos NVMe intensivas. Nada fancy. Solo una carga I/O constante y expectativas estrictas de uptime.
El SRE líder era famosamente aburrido con el control de cambios. Esa aburrida costumbre pagó la renta.

Tenían la práctica: cada actualización de kernel/firmware tenía una prueba previa que incluía una corrida de estrés I/O y una lista de verificación de revisión de logs.
No era heroico. Era programado, documentado y repetible.

Tras una actualización de firmware de plataforma, la prueba de estrés empezó a producir errores AER corregidos en el puerto ascendente NVMe.
Aún no había caídas, ni impacto visible en la aplicación, solo un nuevo tipo de ruido en los logs. La mayoría de equipos lo ignoraría porque “corregido”.

Ellos no lo desplegaron. Bisectaron el cambio: mismo SO, mismo kernel, solo cambió firmware. Los errores siguieron al firmware.
Revirtieron el firmware en ese lote y abrieron un ticket con el proveedor con evidencia limpia: logs de antes/después, pasos de reproducción y salida del estado de enlace.

Semanas después, el proveedor entregó un firmware corregido que ajustó el comportamiento de estados de energía PCIe. El servicio nunca tuvo un outage en producción por eso.
La práctica que los salvó no fue genial; fue negarse a desplegar cuando el sistema empezó a susurrar “no estoy bien.”

Errores comunes: síntoma → causa raíz → solución

Aquí es donde la mayoría de outages pasan de “molestos” a “generadores de reanuncios”.

1) Síntoma: “El sistema de archivos pasó a solo lectura, NVMe debe estar muriendo”

Causa raíz: reinicio de controlador o caída del enlace PCIe causó errores de I/O; el sistema de archivos se remontó a solo lectura para protegerse.

Solución: confirma con journalctl -k los timeouts/reinicios; ataca ASPM/APST/runtime PM; luego valida bajo carga.

2) Síntoma: “SMART está limpio, así que no puede ser el disco”

Causa raíz: inestabilidad de transporte/enlace no necesariamente aparece como errores de medio.

Solución: correlaciona errores AER y reinicios NVMe; revisa el estado del enlace PCIe; trátalo como un problema de estabilidad de plataforma.

3) Síntoma: “Solo ocurre bajo carga, así que es sobrecalentamiento”

Causa raíz: podría ser térmico, pero frecuentemente es temporización de transición de estados de energía bajo profundidad sostenida de colas.

Solución: revisa temperaturas, sí; pero también reproduce con ASPM off o APST limitado. Arreglos térmicos sin confirmación en logs son solo cosplay de HVAC.

4) Síntoma: “Deshabilitar ASPM lo arregló, así que aplicarlo en todas partes”

Causa raíz: política general basada en una combinación mala de plataforma/disco.

Solución: trátalo como específico de perfil de hardware. En portátiles y despliegues sensibles a energía, intenta una solución más estrecha (limitar APST, deshabilitar autosuspend runtime solo para NVMe).

5) Síntoma: “Aumenté nvme io_timeout y ahora no se reinicia”

Causa raíz: convertiste una falla dura en una espera más larga. El dispositivo aún se cuelga; solo esperas más antes de admitirlo.

Solución: revierte tweaks de timeout; arregla la inestabilidad subyacente; usa timeouts para ajustar el comportamiento de recuperación solo después de que la estabilidad esté probada.

6) Síntoma: “Los errores AER corregidos son inofensivos”

Causa raíz: los errores corregidos pueden ser avisos tempranos de un enlace marginal que eventualmente se volverá no corregible bajo estrés.

Solución: monitoriza tasas de errores corregidos; investiga picos; prueba forzar velocidad Gen menor o ajustar ASPM.

7) Síntoma: “Solo ocurre después de inactividad”

Causa raíz: estados de inactividad profunda (ASPM L1.2, APST profundo, autosuspend runtime) más una carga repentina crean una ruta de fallo al despertar.

Solución: deshabilitar autosuspend runtime para NVMe; limitar la latencia máxima APST; considera ASPM off si es necesario.

Segundo y último chiste: si tu NVMe sigue desapareciendo, felicitaciones — has inventado almacenamiento en la nube, excepto que la nube es tu bus PCIe y cobra intereses.

Listas de verificación / plan paso a paso

Paso a paso: estabilizar un NVMe inestable en Ubuntu 24.04 en producción

1. Captura evidencia primero.
   Guarda la salida de journalctl -k -b, lspci -vv para el NVMe y el puerto ascendente, y nvme smart-log.
   Quieres pruebas de antes/después.
2. Determina la clase de fallo.
   Dispositivo desaparecido vs dispositivo atascado. “Desaparecido” apunta fuertemente a PCIe/enlace/energía; “atascado” puede ser energía, firmware o térmico.
3. Reproduce con carga controlada.
   Usa fio en el dispositivo raw si es seguro, o en una partición de prueba dedicada. Observa dmesg -wT en vivo.
4. Cambio inicial: deshabilita ASPM para un arranque.
   Añade pcie_aspm=off. Reproduce de nuevo. Si se arregla, decide si mantenerlo o intentar un arreglo más específico.
5. Cambio segundo: limita APST de NVMe.
   Añade nvme_core.default_ps_max_latency_us=5000 (o similar) y prueba. Ajusta según resultados.
6. Cambio tercero: deshabilita autosuspend runtime para el dispositivo PCI NVMe.
   Pon /sys/bus/pci/devices/.../power/control en on; persiste vía udev si funciona.
7. Valida transiciones inactividad→ráfaga.
   El fallo clásico es “inactivo por 10 minutos, luego pico.” Recrea ese patrón con tu prueba.
8. Revisa BIOS/UEFI si el software no es suficiente.
   Deshabilita ASPM en firmware, fuerza Gen3 o ajusta C-states temporalmente para confirmar la causa raíz.
9. Una vez estable, optimiza con cuidado.
   Rehabilita una función de energía a la vez, mide y detente cuando vuelvan los errores.
10. Operacionaliza las barreras de seguridad.
    Añade alertas para reinicios/timeouts NVMe y picos AER de PCIe. La estabilidad sin detección es solo sorpresa programada.

Lista de reversión (porque la necesitarás)

1. Mantén acceso a la consola (IPMI/iDRAC/KVM) antes de cambiar parámetros del kernel.
2. Documenta la línea previa de /etc/default/grub y guarda una copia.
3. Aplica un cambio persistente a la vez; reinicia; prueba; luego continúa.
4. Si el host falla al arrancar o el comportamiento del almacenamiento cambia, elimina el último parámetro del kernel y regenera GRUB.

Preguntas frecuentes

1) ¿Es esto un bug de Ubuntu 24.04?

A veces se desencadena porque kernels más nuevos son más activos en la gestión de energía, pero la causa raíz suele ser la interacción plataforma/firmware/disco.
Ubuntu es solo donde lo notaste.

2) ¿Debería deshabilitar PCIe ASPM o NVMe APST primero?

Si el NVMe “desaparece” (se cae del bus) y ves ruido AER/enlace, deshabilita ASPM primero.
Si es más “timeouts luego reinicio” sin AER obvio, prueba limitar APST a continuación. En la práctica, ASPM-off es la prueba binaria más rápida.

3) ¿Deshabilitar ASPM afectará el rendimiento?

Usualmente no en términos de throughput. Puede aumentar el consumo en reposo y a veces afectar microcomportamientos de latencia. El verdadero “daño” es la eficiencia energética,
que importa más en portátiles y flotas densas.

4) ¿Deshabilitar APST arruinará la batería en portátiles?

Puede. APST está ahí por una razón. Prefiere limitar la latencia máxima APST en lugar de eliminar la gestión de energía por completo,
y aplica cambios amplios solo a máquinas que lo requieran.

5) Solo veo “AER corrected errors”. ¿Me importa?

Sí, si se correlacionan con picos de carga o preceden timeouts/reinicios NVMe. Los errores corregidos son avisos tempranos.
Si son constantes e inofensivos durante meses, quizá los ignores; si aparecen de repente tras una actualización, investiga.

6) ¿Un cable malo puede causar dropouts de NVMe?

No para M.2 a bordo, pero para U.2/U.3 o backplanes PCIe, absolutamente. Mala integridad de señal se ve como ruido AER y retrain de enlace.
En servidores, “es el cable/backplane” es aburrido y frecuentemente correcto.

7) ¿Debería forzar PCIe Gen3 como solución temporal?

Si necesitas estabilidad hoy y tu enlace es marginal en Gen4/Gen5, forzar Gen3 es una maniobra de triaje válida.
Perderás ancho de banda pico, pero conservarás el sistema de archivos, que suele considerarse un intercambio razonable.

8) ¿Por qué ocurre bajo carga en lugar de en reposo?

La carga aumenta la profundidad de cola, la actividad DMA, las interrupciones y la emisión térmica. También puede generar transiciones rápidas entre ocupado/inactivo.
Esas transiciones son donde la lógica defectuosa de estados de energía tropieza.

9) ¿Aumentar nvme_core.io_timeout es alguna vez buena idea?

Rara vez, y solo cuando has probado que el dispositivo es lento pero estable (por ejemplo, por recolección de basura interna intensa) y los reinicios son contraproducentes.
Para “dispariciones de dispositivo”, los timeouts no son la solución.

10) ¿Cómo demuestro que la solución realmente funcionó?

Usa el mismo reproducer (patrón fio, duración, profundidad de cola), compara logs del kernel para AER/timeouts/reinicios y ejecuta una prueba inactividad→ráfaga.
“Se siente mejor” no es una estrategia de verificación.

Conclusión: pasos prácticos siguientes

Cuando un NVMe desaparece bajo carga en Ubuntu 24.04, normalmente estás frente a un caso límite de gestión de energía:
ASPM en el enlace PCIe, APST en el controlador NVMe, runtime PM en el SO, o alguna encantadora combinación.
La solución rara vez es mística. Es disciplinada: captura logs, reproduce, cambia una perilla y vuelve a probar.

Pasos siguientes que rinden rápido:

• Ejecuta la guía rápida: revisa logs por timeouts/reinicios NVMe y AER de PCIe, confirma si el dispositivo desapareció o quedó atascado.
• Prueba un arranque con pcie_aspm=off. Si la estabilidad vuelve, decide si mantenerlo o probar una solución más específica.
• Si hace falta, limita APST vía nvme_core.default_ps_max_latency_us y/o deshabilita autosuspend runtime para la función PCI NVMe.
• Valida con una carga reproducible y una prueba inactividad→ráfaga, luego operacionaliza alertas para picos AER y reinicios NVMe.