Problema

Los servidores Proxmox pueden experimentar reinicios inesperados acompañados de mensajes como BUG: unable to handle page fault for address o trazas que terminan en __d_lookup+0x58/0xe. Estos kernel panics aparecen sin una causa evidente y dejan al host inoperativo hasta el próximo arranque. El patrón típico incluye:

  • Un crash espontáneo durante la carga de módulos o al ejecutar una VM.
  • Trazas que apuntan a funciones del kernel relacionadas con la gestión de memoria o con módulos de red/almacenamiento.
  • Falta de un error reproducible a través de la configuración de la VM.

Este tipo de fallos no se limitan a una versión concreta de Proxmox; cualquier instalación basada en Debian/Ubuntu con kernel genérico puede verse afectada cuando el hardware, los controladores o los módulos de terceros presentan incompatibilidades.

Causa

1. Módulos de terceros incompatibles

Controladores de tarjetas de red (p.ej. r8125), adaptadores de almacenamiento (nvme_fabrics) o módulos de virtualización (vfio_pci) pueden cargar versiones que no coinciden con la rama del kernel. Cuando el kernel intenta acceder a una estructura de datos que el módulo ha modificado, se produce el page fault.

2. Firmware o BIOS desactualizado

El kernel depende de la tabla de interrupciones y de la configuración de IOMMU provista por el firmware. Un BIOS que no exponga correctamente las capacidades de VT-d o IOMMU genera errores en la capa de vfio_iommu_type1, que aparecen como fallos de acceso a memoria.

3. Memoria RAM defectuosa

Los page faults pueden ser el síntoma de bits erróneos en la RAM. En entornos virtualizados, el kernel a menudo escribe en direcciones altas (ffff8f…) que, si la memoria está corrupta, disparan el panic antes de que el OOM killer actúe.

4. Overclock o configuración de energía agresiva

Ajustes de frecuencia de CPU o de C‑states que el hardware no soporta pueden provocar inestabilidad en la capa de gestión de registros (CR2, CR3, CR4). El kernel registra valores extraños en los registros y finaliza con un BUG.

5. Actualizaciones parciales del kernel

Instalar solo paquetes de módulos sin actualizar el kernel completo deja versiones desalineadas. El kernel intenta ejecutar código de un módulo compilado contra una ABI diferente, lo que genera fallos en funciones como __d_lookup.

Solución

Paso 1 – Recopilar información del crash

Ejecuta journalctl -b -1 -k y guarda la salida completa. Busca:

  • Dirección de CR2 (dirección que provocó el fault).
  • Nombre del módulo que aparece justo antes de la traza (r8125, vfio_pci, etc.).
  • Versión del kernel (uname -r).

Paso 2 – Verificar integridad de la RAM

Arranca con memtest86+ desde el menú de arranque. Completa al menos dos pasadas completas. Si se detectan errores, reemplaza los módulos defectuosos antes de continuar.

Paso 3 – Alinear firmware y BIOS

Actualiza el BIOS/UEFI a la última versión disponible del fabricante. En la configuración, habilita VT-d y desactiva Fast Boot o Secure Boot si no son necesarios. Reinicia y verifica que la opción IOMMU esté activada.

Paso 4 – Auditar módulos de terceros

Lista los módulos cargados con lsmod. Para cada módulo sospechoso (p.ej. r8125, vfio_pci, nvme_fabrics):

modinfo -F filename <modulo>

Comprueba que el archivo pertenece al mismo árbol de versiones que el kernel (/lib/modules/$(uname -r)/). Si no coinciden, reinstala el paquete:

apt-get install --reinstall <paquete-modulo>

En caso de que el controlador sea de un vendor externo (p.ej. driver Realtek r8125), descarga la versión más reciente del sitio del fabricante y recompílala contra el kernel actual.

Paso 5 – Forzar una actualización completa del kernel

Ejecuta:

apt-get update
apt-get full-upgrade

Esto garantiza que el kernel, los encabezados y todos los módulos estén sincronizados. Después de la actualización, reconstruye el initramfs:

update-initramfs -u -k all

Reinicia y observa si el panic persiste.

Paso 6 – Desactivar temporalmente módulos problemáticos

Si la traza indica un módulo específico, impide su carga añadiéndolo a /etc/modprobe.d/blacklist.conf:

echo "blacklist r8125" >> /etc/modprobe.d/blacklist.conf

Reinicia y verifica que el sistema arranque sin panics. Si el problema desaparece, el módulo es el culpable y puedes buscar una versión más estable o reemplazar el hardware asociado.

Paso 7 – Ajustar parámetros de energía

En /etc/default/grub añade al GRUB_CMDLINE_LINUX_DEFAULT:

intel_idle.max_cstate=1 processor.max_cstate=1

Luego actualiza GRUB:

update-grub

Reinicia. Esta configuración limita los estados de ahorro de energía que suelen desencadenar inestabilidad en hardware marginal.

Cuándo aplicar esta solución

  • Síntomas: reinicios inesperados, mensajes BUG: unable to handle page fault, trazas que terminan en __d_lookup o en módulos de red/almacenamiento.
  • Entorno: servidores Proxmox con hardware mixto (NICs Realtek, tarjetas NVMe, GPUs passtrough) y versiones de kernel no muy recientes.
  • No aplica: si el panic ocurre exclusivamente bajo carga de una aplicación específica dentro de una VM y el host nunca se reinicia, el problema probablemente está en la VM, no en el host.

Código

# 1. Exportar logs del último panic
journalctl -b -1 -k > /root/panic_last.log

# 2. Verificar módulos cargados y sus versiones
lsmod | grep -E 'r8125|vfio|nvme'
for mod in r8125 vfio_pci nvme_fabrics; do
    modinfo -F filename $mod 2>/dev/null || true
done

# 3. Forzar actualización completa del kernel y módulos
apt-get update && apt-get full-upgrade -y
update-initramfs -u -k all
update-grub

# 4. Blacklist un módulo problemático (ejemplo r8125)
echo "blacklist r8125" >> /etc/modprobe.d/blacklist.conf

# 5. Limitar C‑states para pruebas de estabilidad
sed -i 's/^GRUB_CMDLINE_LINUX_DEFAULT=.*/GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=1 processor.max_cstate=1"/' /etc/default/grub
update-grub

Verificación

  1. Reinicia el host y observa el arranque. Si el kernel llega al login sin detenerse, el panic se ha mitigado.
  2. Reproduce carga ejecutando una VM que previamente provocaba el crash. Monitorea dmesg -w durante los primeros minutos.
  3. Revisa logs: grep -i panic /var/log/kern.log o journalctl -b -0 | grep -i panic. Ausencia de entradas indica éxito.
  4. Valida memoria: si memtest86+ sigue reportando errores, reemplaza la RAM antes de considerar el problema resuelto.

Notas adicionales

  • En entornos con passthrough de GPU, el driver vfio_pci es una causa frecuente. Asegúrate de que el IOMMU esté activo y que el dispositivo no esté también enlazado al driver nativo de la GPU.
  • Cuando uses tarjetas de red Realtek (r8125), la versión del driver incluida en los repositorios suele ser más estable que la del sitio del fabricante. Prefiere el paquete del repositorio a menos que necesites características específicas.
  • Si después de alinear firmware y módulos el panic persiste, considera probar una versión LTS del kernel (p.ej. 5.15) que ofrezca mayor madurez para hardware antiguo.
  • Mantén siempre una copia de seguridad de la configuración de Proxmox (/etc/pve) antes de aplicar cambios drásticos en el kernel o en los módulos.