Cómo resolver problemas gráficos complejos en Intel UHD Graphics 620 mediante diagnóstico sistemático y parámetros del kernel

Hace dos meses, mi Slimbook Pro 2019 comenzó a mostrar síntomas que cualquier técnico habría diagnosticado como «hardware muerto»: pantalla interna parpadeando constantemente, sistema extremadamente lento, sesiones gráficas que se colgaban al arrancar. Después de cinco años de funcionamiento perfecto, parecía que había llegado el momento de reemplazarlo.

Sin embargo, la persistencia y un enfoque sistemático de diagnóstico demostraron que incluso los problemas más graves pueden tener soluciones inesperadas. Este es el relato completo de cómo conseguí que un portátil «desahuciado» volviera a funcionar perfectamente, incluso ejecutando Cinnamon con efectos activados.

Estado Inicial: Síntomas del Problema

Hardware afectado:

• Slimbook Pro (2019) con Intel Core i7 Comet Lake-U
• Intel UHD Graphics 620 integrada
• Sistema operativo: Debian GNU/Linux
• Monitor externo: IProda PD182Kpn (portátil, ideal para complementar el portátil)

Síntomas observados:

• Pantalla interna parpadeando constantemente en negro (problema principal)
• Sistema extremadamente lento, incluso con monitor externo conectado
• Sesiones gráficas que fallan al arrancar o se cuelgan
• Interfaz gráfica prácticamente inusable
• Modo consola funcionando correctamente

Contexto temporal: El portátil funcionó perfectamente desde 2019 hasta aproximadamente julio-agosto de 2025, cuando los problemas aparecieron súbitamente sin cambios significativos en hardware o software.

Primera Fase: Diagnóstico y Descarte de Causas Obvias

Análisis de Logs del Sistema

El primer paso fue examinar los logs del kernel para identificar la causa raíz:

sudo dmesg | grep -i "i915"

Los logs revelaron información crítica sobre el controlador de Intel Graphics:

i915 0000:00:02.0: [drm] Found cometlake/ult (device ID 9b41)
WARNING: CPU: 0 PID: 176 at drivers/gpu/drm/i915/display/intel_pps.c:974 intel_pps_on_unlocked

Hallazgo clave: Error en la secuencia de encendido del panel (Panel Power Sequence), indicando problemas en la gestión de energía de la pantalla interna.

Verificación del Estado de las Pantallas

cat /sys/class/drm/*/status
# Resultado: 
# disconnected
# connected    # Pantalla interna (eDP-1) - causando problemas
# disconnected  
# connected    # Monitor externo HDMI-2

Ambas pantallas eran detectadas correctamente por el kernel, pero la interna (eDP-1) estaba causando inestabilidad al sistema completo.

Análisis de Aceleración Gráfica

glxinfo | grep -E "(OpenGL renderer|direct rendering)"

En este punto, el sistema mostró renderizado por software (llvmpipe), indicando que la aceleración hardware había fallado, explicando la extrema lentitud del sistema.

Segunda Fase: Estrategias de Solución Sistemática

Intento 1: Parámetros del Controlador i915

Basándome en la investigación sobre problemas conocidos del Intel UHD Graphics 620 en Comet Lake, implementé los primeros parámetros correctivos en GRUB:

sudo nano /etc/default/grub

# Configuración inicial
GRUB_CMDLINE_LINUX_DEFAULT="i915.enable_psr=0 i915.enable_rc6=0 i915.enable_guc=2 i915.enable_dc=0"

sudo update-grub && sudo reboot

Explicación de parámetros:

• enable_psr=0: Desactiva Panel Self Refresh (causa común de parpadeo)
• enable_rc6=0: Evita estados de bajo consumo problemáticos
• enable_guc=2: Fuerza carga del firmware GuC/HuC
• enable_dc=0: Desactiva Display C-states problemáticos en Comet Lake

Resultado: Mejora marginal, pero el parpadeo de la pantalla interna persistía.

Intento 2: Gestión de Controladores y Configuración de Xorg

Cambié del controlador Intel tradicional al controlador modesetting más moderno:

sudo nano /etc/X11/xorg.conf.d/20-intel.conf

# Configuración
Section "Device"
    Identifier "Intel Graphics"
    Driver "modesetting"
    Option "AccelMethod" "glamor"
    Option "TearFree" "true"
EndSection

Resultado: Sin mejoras significativas en la estabilidad.

Intento 3: Gestión del Gestor de Pantalla

Los problemas con SDDM llevaron a configurar scripts de inicialización para desactivar automáticamente la pantalla interna:

sudo nano /usr/share/sddm/scripts/Xsetup

#!/bin/bash
sleep 3
xrandr --output eDP-1 --off --output HDMI-2 --auto --primary

Resultado: Mejoras temporales que no persistían entre reinicios, y la pantalla interna seguía parpadeando durante el arranque.

Tercera Fase: El Breakthrough – Gestión de Energía PCIe y Desactivación a Nivel Kernel

Identificación del Problema Real

Un análisis más profundo de los logs reveló errores críticos que habían pasado desapercibidos:

sudo tail -f /var/log/Xorg.0.log

(WW) modeset(0): hotplug event: connector 106's link-state is BAD, tried resetting the current mode. You may be left with a black screen if this fails...

Este mensaje aparecía repetidamente cada 1-2 segundos, indicando que el problema no era el renderizado gráfico sino la estabilidad de la conexión de los displays.

La Solución Dual: PCIe ASPM + Desactivación de Pantalla Interna

La solución final requirió dos enfoques complementarios:

1. Desactivar la gestión de energía PCIe que causaba inestabilidad
2. Desactivar completamente la pantalla interna a nivel de kernel para evitar que cause conflictos

sudo nano /etc/default/grub

# Configuración que solucionó el problema
GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=igfx_off i915.enable_prs=0 i915.modeset=1 i915.enable_rc6=0 i915.enable_guc=2 i915.enable_dc=0 plymouth.enable=0 i915.enable_fbc=0 video=HDMI-2:1920x1080@60 video=eDP-1:d pcie_aspm=off"

Parámetros clave explicados:

Gestión de energía y estabilidad:

• pcie_aspm=off: Crítico – Desactiva Active State Power Management de PCIe, resuelve errores «link-state BAD»
• intel_iommu=igfx_off: Evita conflictos de mapeo de memoria con gráficos Intel
• plymouth.enable=0: Desactiva pantalla de arranque problemática

Configuración del controlador i915:

• i915.enable_prs=0: Desactiva Panel Self Refresh (parpadeo)
• i915.enable_dc=0: Desactiva Display C-states problemáticos en Comet Lake
• i915.enable_rc6=0: Evita estados de bajo consumo problemáticos
• i915.enable_guc=2: Fuerza carga del firmware GuC/HuC para mejor rendimiento
• i915.modeset=1: Activa mode setting del kernel
• i915.enable_fbc=0: Desactiva Frame Buffer Compression

Configuración de pantallas:

• video=HDMI-2:1920x1080@60: Fuerza resolución específica para el monitor externo
• video=eDP-1:d: Desactiva completamente la pantalla interna a nivel de kernel (el parámetro :d significa «disabled»)

¿Por qué era Necesaria la Desactivación a Nivel Kernel?

La pantalla interna parpadeante no solo era molesta visualmente, sino que causaba inestabilidad en todo el subsistema gráfico. Los intentos de desactivarla a nivel de Xorg (xrandr --output eDP-1 --off) llegaban demasiado tarde: el kernel ya había inicializado ambas pantallas y la interna ya había comenzado a causar problemas.

El parámetro video=eDP-1:d instruye al kernel para que ignore completamente la pantalla interna durante el arranque, evitando que se inicialice y cause conflictos con el controlador de display.

Cuarta Fase: Verificación del Éxito

Resultados Inmediatos

Tras el reinicio con la configuración final:

# Verificación de aceleración hardware
glxinfo | grep "OpenGL renderer"
# Resultado: Mesa Intel(R) UHD Graphics (CML GT2)

# Test de rendimiento
vblank_mode=0 glxgears
# Resultado: ~7500 FPS

# Benchmark completo
glmark2 --fullscreen
# Puntuación: 590 (excelente para gráficos integrados)

Cambios observados:

• Pantalla interna completamente silenciosa – sin parpadeos desde el arranque
• Arranque limpio – sin errores «link-state BAD» en los logs
• Aceleración hardware restaurada – renderizado por hardware, no software
• Sistema responsivo – rendimiento normal restaurado

Resultados Finales

Estado Actual del Sistema

Hardware gráfico:

• Aceleración hardware completamente funcional
• Intel UHD Graphics 620 operando a pleno rendimiento
• Monitor externo IProda PD182Kpn funcionando a 1920×1080@60Hz estable
• Pantalla interna completamente desactivada – sin parpadeos

Rendimiento del sistema:

• Entorno de escritorio: Cinnamon con efectos activados
• Rendimiento gráfico: 590 puntos en glmark2
• Estabilidad: Sin errores «link-state BAD» en más de una semana de uso intensivo
• Arranque limpio sin interferencias de la pantalla problemática

Funcionalidades restauradas:

• Sesiones gráficas estables
• Reproducción de video fluida
• Navegación web sin problemas
• Capacidad para ejecutar entornos de escritorio modernos

Validación de la Solución

El sistema ahora supera las expectativas iniciales:

# Test de texto 2D (relevante para trabajo de oficina)
x11perf -aa10text
# Resultado: 11M caracteres/segundo

# Test de renderizado 3D básico
glxgears (con vsync)
# Resultado: 60 FPS estables sin caídas

# Test sin vsync (rendimiento real)
vblank_mode=0 glxgears  
# Resultado: 7500+ FPS

Lecciones Técnicas Aprendidas

1. Los Síntomas Pueden Engañar

Los síntomas (pantalla parpadeando, sistema lento) apuntaban a fallo de hardware gráfico. La realidad era un problema de gestión de energía PCIe que afectaba la estabilidad de las conexiones de display, más una pantalla interna defectuosa que interfería con todo el subsistema.

2. La Importancia del Diagnóstico Profundo

El error crítico «connector link-state BAD» solo era visible en logs específicos de Xorg, no en los logs generales del kernel. El diagnóstico superficial habría llevado a conclusiones erróneas.

3. Soluciones Múltiples vs Solución Única

El problema requería dos soluciones complementarias:

• Estabilizar las conexiones PCIe (pcie_aspm=off)
• Eliminar la fuente de conflictos (video=eDP-1:d)

Una sola no era suficiente.

4. Nivel de Intervención Importante

Desactivar la pantalla a nivel de aplicación (xrandr) llegaba tarde. Era necesario intervenir a nivel de kernel para evitar que el problema se manifestara desde el inicio.

Metodología de Diagnóstico Replicable

Para técnicos que enfrenten problemas similares:

Paso 1: Recolección de Información

# Información del hardware
lspci | grep VGA
dmidecode -s system-manufacturer
dmidecode -s bios-version

# Estado de displays
cat /sys/class/drm/*/status
xrandr (si es accesible)

# Logs críticos
dmesg | grep -i "drm\|i915"
journalctl -xe | grep -i "graphics\|display"
tail -f /var/log/Xorg.0.log | grep -i "hotplug\|link-state"

Paso 2: Identificación de Patrones

• Parpadeo constante de pantalla = problema hardware específico de esa pantalla
• Errores «link-state BAD» repetitivos = problema de gestión de energía PCIe
• «llvmpipe» en renderizado = falta aceleración hardware (consecuencia)
• Errores al inicializar sesión gráfica = inestabilidad del controlador de display

Paso 3: Soluciones Incrementales

1. Parámetros básicos del controlador i915
2. Configuración de Xorg optimizada
3. Gestión de energía PCIe (crítico)
4. Desactivación de hardware problemático a nivel kernel
5. Optimización específica por hardware

Reflexiones sobre la Persistencia Técnica

Este caso demuestra que el diagnóstico «hardware muerto» debe cuestionarse sistemáticamente. La tendencia a descartar hardware aparentemente fallido puede llevar a:

• Pérdida económica innecesaria: Un portátil de €500 salvado vs €1000+ en reemplazo
• Impacto ambiental: Evitar desecho prematuro de hardware funcional
• Pérdida de datos y configuraciones: Mantener el entorno de trabajo existente

Cuándo Persistir vs Cuándo Rendirse

Indicadores para continuar el diagnóstico:

• Hardware con historial de funcionamiento estable
• Fallo súbito sin causa aparente
• Funcionalidad parcial (consola funcionando)
• Errores específicos en logs (no fallos aleatorios)
• Un solo componente problemático identificable

Indicadores para considerar reemplazo:

• Múltiples componentes fallando simultáneamente
• Errores de memoria física o CPU
• Fallos intermitentes sin patrón reproducible
• Costo de reparación > 60% del valor del equipo

Configuración del Monitor Externo IProda PD182Kpn

Una nota específica sobre el monitor portátil utilizado: el IProda PD182Kpn demostró ser un excelente compañero para el portátil reparado:

Especificaciones relevantes:

• Panel IPS de 18.5″ Full HD (1920×1080)
• Conexión HDMI estable con el controlador Intel UHD 620
• Alimentación via USB-C (compatible con puertos del Slimbook)
• Perfil delgado ideal para trabajar en movilidad

Configuración óptima:

# Forzar resolución y frecuencia específicas
xrandr --output HDMI-2 --mode 1920x1080 --rate 60

# Configuración permanente en GRUB
video=HDMI-2:1920x1080@60

Este monitor demostró ser ideal para validar la solución, ya que requiere una señal HDMI completamente estable – cualquier inestabilidad en el controlador gráfico se manifestaría inmediatamente como parpadeos o desconexiones.

Conclusión: El Valor de la Persistencia Técnica

Lo que inicialmente parecía un fallo irreversible de hardware se resolvió completamente mediante:

1. Diagnóstico sistemático en lugar de asunciones basadas en síntomas
2. Investigación específica sobre el hardware exacto (Comet Lake + UHD 620)
3. Identificación de componentes problemáticos específicos (pantalla interna)
4. Soluciones a múltiples niveles (kernel + drivers + gestión de energía)
5. Documentación detallada de cada intento para evitar repeticiones

El resultado final supera las expectativas iniciales: un sistema que no solo funciona, sino que rinde mejor de lo esperado para gráficos integrados de 2019. La capacidad de ejecutar Cinnamon con efectos activados demuestra que el hardware tenía potencial que estaba siendo bloqueado por configuraciones subóptimas y un componente específico defectuoso.

Para cualquier técnico enfrentando problemas similares, el mensaje clave es: antes de declarar hardware muerto, agota las posibilidades de configuración y aísla componentes problemáticos. Los sistemas modernos tienen tantas capas de abstracción (kernel, drivers, gestión de energía, protocolos de display) que los problemas aparentemente de hardware a menudo tienen soluciones de software, especialmente cuando se puede identificar y desactivar el componente específico que causa conflictos.

La persistencia técnica, combinada con metodología sistemática, puede salvar hardware que de otra manera terminaría prematuramente en el desecho. En un mundo donde la sostenibilidad tecnológica es cada vez más importante, estas victorias tienen valor tanto económico como ambiental.

El Slimbook Pro 2019 ha vuelto a la vida, demostrando que a veces lo que parece el final es solo un problema esperando la solución correcta – y la determinación para encontrarla.