Depuración de USB remote wakeup y suspend/resume

Los bugs de USB power management son difíciles de diagnosticar porque el dispositivo puede funcionar perfectamente mientras el sistema está activo y fallar solo tras idle, sleep, selective suspend, dock sleep, cierre de la tapa del portátil o apagado del monitor. Los usuarios buscan "USB remote wakeup not working", "USB selective suspend disconnect", "USB device does not wake computer", "USB resume failure", "USB suspend resume bug" y "HID keyboard wake from sleep not working".

Bus Scope ayuda porque suspend y resume son eventos a nivel de bus, no solo errores de aplicación. Necesitas ver si el host suspendió el dispositivo, si se habilitó remote wakeup, si el dispositivo señaló el resume, si el host reanudó el tráfico y si el dispositivo reenumera en lugar de hacer resume.

Qué significa remote wakeup

Remote wakeup permite a un dispositivo USB suspendido pedir al host que reanude la comunicación. Ejemplos habituales:

• El teclado despierta un escritorio en sleep.
• El ratón despierta un portátil del idle.
• El botón del dock despierta una workstation.
• El escáner de códigos despierta un kiosko.
• Un controlador industrial despierta un panel PC.
• Un sensor HID despierta un host tras un evento externo.

Remote wakeup no es simplemente "el dispositivo tiene power". El host tiene que permitirlo, el dispositivo tiene que anunciar el soporte, la feature tiene que estar habilitada y la señalización de resume tiene que ocurrir en el momento correcto.

Síntomas habituales

Los problemas de remote wakeup y suspend aparecen como:

• El dispositivo va hasta que el PC se duerme.
• El dispositivo no despierta al ordenador.
• El dispositivo despierta el sistema justo después del suspend.
• El dispositivo desaparece tras el resume.
• El dispositivo reenumera con una dirección nueva.
• Se pierde input HID tras el idle.
• El dispositivo serie deja de mandar tras selective suspend.
• El dispositivo de audio o cámara vuelve del sleep sin datos.
• El firmware solo se recupera tras desenchufar y volver a enchufar.

Esos síntomas suelen echarse a los drivers, pero la captura puede enseñar un problema de estado de power del firmware.

Evidencia de descriptor y de feature

El configuration descriptor puede anunciar la capacidad de remote wakeup. El host puede entonces habilitar o deshabilitar la feature de remote wakeup. Una traza útil de diagnóstico USB debería responder:

• ¿El dispositivo anuncia remote wakeup?
• ¿El host mandó SET_FEATURE(DEVICE_REMOTE_WAKEUP)?
• ¿El host limpió después la feature?
• ¿Pasó el suspend tras el idle?
• ¿El dispositivo intentó señalizar el resume?
• ¿El host reanudó las transferencias normales?

Sin esos hechos, el diagnóstico es pura suposición.

Selective suspend

Selective suspend permite al sistema operativo suspender un dispositivo USB inactivo sin dormir el sistema entero. Ahorra energía, pero expone bugs del firmware.

Patrones de fallo:

• El dispositivo entra en bajo consumo pero no restaura el estado del endpoint.
• El firmware pierde el estado pendiente del interrupt IN.
• El dispositivo hace NAK para siempre tras el resume.
• El host resetea el dispositivo tras el timeout.
• La aplicación ve timeout o eliminación del dispositivo.
• El dispositivo compuesto reanuda una interfaz pero no otra.

Quien busca suele escribir "USB selective suspend random disconnect" porque el dispositivo parece desconectarse aunque el evento real sea un fallo de suspend/resume.

Resume frente a re-enumeración

Tras un sleep hay dos desenlaces muy distintos:

• Resume: el mismo dispositivo continúa con la configuración existente.
• Re-enumeración: el host resetea y enumera el dispositivo de nuevo.

La re-enumeración puede ser aceptable tras una desconexión física, pero es sospechosa tras un suspend normal. Puede romper aplicaciones que mantienen handles abiertos, nombres de puerto serie, paths HID o sesiones de captura de cámara.

Bus Scope debería ayudar a identificar si la traza contiene tráfico de resume normal o una nueva secuencia de enumeración con GET_DESCRIPTOR, SET_ADDRESS y SET_CONFIGURATION.

Wake events perdidos

A veces el dispositivo ve el evento externo pero el host no despierta. Las causas incluyen:

• Remote wakeup no anunciado.
• Remote wakeup no habilitado por el host.
• El dispositivo manda resume demasiado pronto.
• El dispositivo manda resume demasiado tarde.
• El hub bloquea o maneja mal la señalización de wake.
• La BIOS o la política de wake del SO deshabilita el puerto.
• El firmware del dispositivo entra en un sleep más profundo de lo esperado.
• El evento ocurre antes de que el suspend termine.

La evidencia a nivel de paquete no sustituye a la política de power del SO, pero acota la pregunta. ¿Tenía permiso el dispositivo para despertar al host, e intentó hacerlo?

Wake inmediato tras suspend

El problema opuesto también es habitual: el sistema suspende y se despierta al instante. Los dispositivos USB pueden causarlo cuando señalan wake por input obsoleto, estado de interrupt ruidoso, bugs de debounce o firmware que trata el suspend como evento nuevo.

Evidencia a recoger:

• Último interrupt report antes del suspend.
• Si el host habilitó wake.
• Timing entre suspend y resume.
• Clase e interfaz del dispositivo.
• Si el mismo endpoint tenía datos pendientes.
• Si el evento se repite en cada intento de suspend.

Es especialmente común con teclados, ratones, paneles táctiles, game controllers y dispositivos HID a medida.

Checklist de depuración

Usa este proceso:

1. Captura la enumeración desde el plug-in.
2. Confirma la capacidad de remote wakeup en los descriptores.
3. Comprueba si el host habilita remote wakeup.
4. Apunta el periodo de idle antes del suspend.
5. Identifica el timing del suspend.
6. Busca señalización de resume o tráfico de resume del host.
7. Separa resume de una re-enumeración completa.
8. Revisa el comportamiento del endpoint tras el resume.
9. Compara el mismo dispositivo en puerto directo y a través de un hub.
10. Conserva los paquetes pre-suspend y post-resume.

Diagnóstico final

Los bugs de remote wakeup y suspend/resume USB son problemas de protocolo de estado de power. La evidencia útil es la capacidad del descriptor, la selección de feature del host, el timing del suspend, la señalización del resume, la recuperación del endpoint y si el host reanudó o reenumera el dispositivo.

Bus Scope ayuda a hacer visible esa evidencia para que "USB wake no va" se vuelva un diagnóstico concreto en lugar de un bucle de echar la culpa al driver.