Depuración de USB selective suspend: desconexiones aleatorias, fallos de sleep/resume y transferencias perdidas

USB selective suspend debería ahorrar energía. Cuando va, los dispositivos inactivos entran en bajo consumo y se despiertan al hacer falta. Cuando falla, los usuarios ven desconexiones aleatorias, datos perdidos, cámaras congeladas, puertos serie que dejan de responder, dispositivos HID que pierden input o dispositivos que desaparecen tras el sleep. Búsquedas como "USB selective suspend random disconnect", "USB device stops working after idle", "USB resume failure" y "disable USB selective suspend" suelen venir de gente que ya probó cables y drivers.

Deshabilitar selective suspend puede ser un workaround, pero no es un diagnóstico. La pregunta real es si falla el dispositivo, el driver, el hub, el host controller o la aplicación durante suspend/resume o la recuperación tras idle.

Bus Scope ayuda porque el fallo tiene una línea de tiempo. Necesitas saber qué tráfico hubo antes del idle, si el host suspendió el camino, qué petición reanudó el dispositivo y qué transferencia falló tras el resume.

Qué hace selective suspend

Selective suspend permite al sistema operativo suspender un dispositivo o interfaz USB individual mientras el resto del sistema sigue activo. Eso es distinto del sleep completo del sistema. Un dispositivo USB se puede suspender porque parece idle aunque el equipo esté despierto en general.

Importa para:

• Adaptadores serie USB.
• Dispositivos HID.
• Cámaras USB.
• Interfaces de audio.
• Sondas de debug.
• Tokens de seguridad.
• Dispositivos vendor a medida.
• Sensores bus-powered.

Si el firmware del dispositivo no maneja bien suspend/resume, la primera transferencia tras el idle puede fallar.

Síntomas típicos

Los problemas de selective suspend suelen parecerse a:

• El dispositivo va tras enchufarlo pero falla a los pocos minutos.
• El primer comando tras idle hace timeout.
• El read serie se queda bloqueado para siempre tras inactividad.
• La preview de la cámara se congela tras el bloqueo de pantalla.
• Los HID reports se paran hasta desenchufar y volver a enchufar.
• El dispositivo se reconecta con una dirección nueva.
• La aplicación dice que el dispositivo se desconectó aunque sigue físicamente conectado.
• Windows o Linux registran mensajes relacionados con reset o resume.

El patrón clave es el tiempo. Si el fallo sigue a periodos de idle, sleep/resume, apagado del display o cambios de estado de power del portátil, el power management entra en la investigación.

Fallo de suspend frente a fallo de resume

Hay dos problemas distintos:

• Fallo de suspend: el dispositivo o el driver no entran bien en bajo consumo.
• Fallo de resume: el dispositivo entra en bajo consumo pero no vuelve correctamente.

Para el usuario, ambos se parecen a "dispositivo desconectado". La traza USB puede separarlos enseñando si el tráfico se paró limpio y si la siguiente petición tras idle falló.

Si el dispositivo desaparece solo tras una orden de la aplicación tras idle, sospecha resume o restauración de estado del firmware. Si el dispositivo se resetea en idle sin petición de la aplicación, sospecha power management del host, comportamiento del hub o watchdog del firmware del dispositivo.

La primera transferencia tras idle

La primera transferencia tras idle suele ser la evidencia más importante. Puede ser:

• Una petición de control.
• Un read o write bulk.
• Un poll de interrupt IN.
• Una class-specific request.
• Un comando vendor.
• Una petición de restart de stream.

Si la primera transferencia hace timeout, STALL o dispara un reset, lo más probable es que el dispositivo no haya vuelto al estado esperado. El arreglo puede ir por el manejo de resume del firmware, la política de power del driver, el comportamiento de reintento de la aplicación, o deshabilitar selective suspend para ese dispositivo.

Runtime power management en Linux

Linux también tiene runtime power management para USB. Los dispositivos pueden autosuspenderse tras un delay de idle. Un dispositivo puede comportarse distinto según el driver, la versión de kernel, los ajustes de autosuspend y si una aplicación mantiene el dispositivo abierto.

Para investigar en Linux, captura el tráfico y correlaciona con logs del sistema. Si el dispositivo reanuda y se resetea inmediatamente, la traza del bus es más útil que un genérico "I/O error" de la aplicación.

Selective suspend en Windows

En Windows, el comportamiento de selective suspend depende del plan de energía, el soporte del driver, los ajustes del hub USB y la clase del dispositivo. Los usuarios suelen desactivar "USB selective suspend setting" en las opciones de energía. Puede ser un workaround práctico, pero un diagnóstico profesional debería explicar si el dispositivo falló durante la recuperación tras idle.

Los problemas USB en Windows también pueden depender de Modern Standby, comportamiento del dock del portátil, hubs y drivers del host controller. Un dispositivo puede ir en un escritorio y fallar en el dock de un portátil porque el comportamiento de suspend y resume cambia.

Estrategia de captura

Para capturar un bug de selective suspend:

1. Arranca la captura mientras el dispositivo va.
2. Realiza una operación correcta conocida.
3. Deja el dispositivo idle lo bastante como para disparar el problema.
4. Realiza la operación que suele fallar.
5. Sigue capturando hasta el timeout, reset o reconexión.
6. Guarda la ventana completa de timing.

No arranques la captura cuando el dispositivo ya falló. Necesitas la transición de activo a idle y a fallo.

Qué buscar en la traza

Inspecciona:

• Última transferencia antes del idle.
• Hueco de tiempo antes del fallo.
• Primera transferencia tras idle.
• Timeout, stall, reset o desconexión.
• Re-enumeración tras el fallo.
• Cambio en la dirección del dispositivo.
• Class-specific request tras resume.
• Recuperación de halt en endpoint.
• Cambios de alternate setting para dispositivos de streaming.

El timing no es ruido aquí. El timing es la evidencia.

Checklist de depuración

Usa este orden:

1. Confirma si los fallos correlacionan con el tiempo de idle.
2. Prueba con alimentación AC y con batería.
3. Prueba puerto directo frente a hub o dock.
4. Captura antes del idle y durante el fallo.
5. Identifica la primera transferencia fallida tras idle.
6. Mira si el dispositivo se resetea o solo falla una transferencia.
7. Compara con selective suspend deshabilitado.
8. Compara con otro SO u otro host controller.
9. Revisa el manejo de resume del firmware.
10. Revisa la política de power del driver y el comportamiento de reintento de la aplicación.

Diagnóstico final

Los problemas de USB selective suspend no se resuelven bien adivinando. Deshabilitar el power management puede aliviar los síntomas, pero la respuesta de ingeniería de verdad viene de la línea de tiempo USB: tráfico activo, hueco de idle, intento de resume, transferencia fallida, reset o recuperación.

Bus Scope ayuda a conservar e inspeccionar esa evidencia para que una "desconexión aleatoria de USB" se pueda diagnosticar como un fallo concreto de suspend/resume, driver, firmware, hub o power management.