Débogage de la selective suspend USB : déconnexions aléatoires, échecs de sleep/resume et transferts manquants

La selective suspend USB est censée économiser de l'énergie. Quand elle marche, les périphériques inactifs entrent dans un état de basse consommation et resume quand nécessaire. Quand elle échoue, les utilisateurs voient des déconnexions aléatoires, des données manquantes, des caméras gelées, des ports série qui cessent de répondre, des périphériques HID qui manquent d'entrées, ou des périphériques qui disparaissent après la veille. Les recherches comme « USB selective suspend random disconnect », « USB device stops working after idle », « USB resume failure » et « disable USB selective suspend » viennent généralement de personnes qui ont déjà essayé les câbles et les pilotes.

Désactiver la selective suspend peut être un contournement, mais ce n'est pas un diagnostic. La vraie question est de savoir si le périphérique, pilote, hub, contrôleur hôte ou application échoue pendant le suspend/resume ou la récupération après inactivité.

Bus Scope aide car la défaillance a une chronologie. Vous devez savoir quel trafic s'est produit avant l'inactivité, si l'hôte a suspendu le chemin, quelle requête a resume le périphérique, et quel transfert a échoué après le resume.

Ce que fait la selective suspend

La selective suspend permet au système d'exploitation de suspendre un périphérique ou interface USB individuel pendant que le reste du système reste actif. C'est différent de la veille système complète. Un périphérique USB peut être suspendu parce qu'il semble inactif même si l'ordinateur est autrement éveillé.

Cela compte pour :

• adaptateurs série USB
• périphériques HID
• caméras USB
• interfaces audio
• sondes de debug
• tokens de sécurité
• périphériques vendor personnalisés
• capteurs bus-powered

Si le firmware du périphérique ne gère pas correctement le suspend/resume, le premier transfert après inactivité peut échouer.

Symptômes typiques

Les problèmes de selective suspend ressemblent souvent à :

• Périphérique marche après branchement mais échoue après quelques minutes.
• Première commande après inactivité timeout.
• Lecture série bloque pour toujours après inactivité.
• Aperçu caméra gelé après verrouillage d'écran.
• Rapports HID s'arrêtent jusqu'à débranchement/rebranchement.
• Périphérique se reconnecte avec une nouvelle adresse.
• L'application dit « device disconnected » même s'il est encore physiquement attaché.
• Windows ou Linux log des messages liés au reset ou au resume.

Le motif clé est le temps. Si la défaillance suit les périodes d'inactivité, sleep/resume, extinction d'écran ou changements d'état d'alimentation du laptop, la gestion d'alimentation fait partie de l'investigation.

Échec de suspend vs échec de resume

Il y a deux problèmes différents :

• Échec de suspend : le périphérique ou pilote ne peut pas entrer en basse consommation correctement.
• Échec de resume : le périphérique entre en basse consommation mais ne revient pas correctement.

Du point de vue utilisateur, les deux peuvent ressembler à « device disconnected ». La trace USB peut les séparer en montrant si le trafic s'est arrêté proprement et si la requête suivante après inactivité a échoué.

Si le périphérique disparaît seulement après que l'application a envoyé une commande après inactivité, suspectez le resume ou la restauration d'état firmware. Si le périphérique reset pendant l'inactivité sans requête applicative, suspectez la gestion d'alimentation de l'hôte, le comportement du hub ou le watchdog firmware du périphérique.

Premier transfert après inactivité

Le premier transfert après inactivité est souvent la preuve la plus importante. Il peut être :

• Une requête de contrôle.
• Une lecture ou écriture bulk.
• Un poll interrupt IN.
• Une requête spécifique à la classe.
• Une commande vendor.
• Une requête de redémarrage de flux.

Si le premier transfert timeout, stall ou déclenche un reset, le périphérique n'est probablement pas resume dans l'état attendu. Le correctif peut être la gestion du resume firmware, la politique d'alimentation du pilote, le comportement de retry applicatif, ou la désactivation de la selective suspend pour ce périphérique.

Runtime power management sous Linux

Linux a aussi le runtime power management USB. Les périphériques peuvent autosuspend après un délai d'inactivité. Un périphérique peut se comporter différemment selon le pilote, la version du noyau, les paramètres d'autosuspend, et si une application maintient le périphérique ouvert.

Pour les investigations Linux, capturez le trafic et corrélez avec les logs système. Si le périphérique resume et reset immédiatement, la trace de bus est plus utile qu'un vague « I/O error » applicatif.

Selective suspend sous Windows

Sous Windows, le comportement de selective suspend dépend du plan d'alimentation, du support pilote, des paramètres du hub USB et de la class du périphérique. Les utilisateurs désactivent souvent « USB selective suspend setting » dans les options d'alimentation. C'est un contournement pratique, mais un diagnostic professionnel doit quand même expliquer si le périphérique a échoué pendant la récupération après inactivité.

Les problèmes USB Windows peuvent aussi être affectés par Modern Standby, le comportement du dock de laptop, les hubs et les pilotes de contrôleur hôte. Un périphérique peut marcher sur un desktop mais échouer sur un dock de laptop car le comportement de suspend/resume diffère.

Stratégie de capture

Pour capturer un bug de selective suspend :

1. Démarrez la capture pendant que le périphérique marche.
2. Effectuez une opération réputée réussie.
3. Laissez le périphérique inactif assez longtemps pour déclencher le problème.
4. Effectuez l'opération qui échoue habituellement.
5. Continuez la capture jusqu'au timeout, reset ou reconnexion.
6. Enregistrez la fenêtre de timing complète.

Ne démarrez pas la capture seulement après que le périphérique a déjà échoué. Vous avez besoin de la transition d'actif à inactif vers la défaillance.

Que chercher

Dans la trace, inspectez :

• Dernier transfert avant inactivité.
• Gap de temps avant la défaillance.
• Premier transfert après inactivité.
• Timeout, stall, reset ou déconnexion.
• Ré-énumération après défaillance.
• Changement d'adresse de périphérique.
• Requête spécifique à la classe après resume.
• Récupération de halt d'endpoint.
• Changements d'alternate setting pour les périphériques de streaming.

Le timing n'est pas du bruit ici. Le timing est la preuve.

Checklist de débogage

Suivez cet ordre :

1. Confirmez si les défaillances corrèlent avec le temps d'inactivité.
2. Testez sur secteur et sur batterie.
3. Testez port direct vs hub ou dock.
4. Capturez avant inactivité et jusqu'à la défaillance.
5. Identifiez le premier transfert échoué après inactivité.
6. Vérifiez si le périphérique reset ou seul un transfert échoue.
7. Comparez avec selective suspend désactivée.
8. Comparez avec un autre OS ou contrôleur hôte.
9. Vérifiez la gestion du resume firmware.
10. Vérifiez la politique d'alimentation du pilote et le comportement de retry applicatif.

Diagnostic final

Les problèmes de selective suspend USB ne se résolvent pas bien en devinant. Désactiver la gestion d'alimentation peut réduire les symptômes, mais la vraie réponse d'ingénierie vient de la chronologie USB : trafic actif, gap d'inactivité, tentative de resume, transfert échoué, reset ou récupération.

Bus Scope aide à conserver et inspecter cette preuve pour qu'une « random USB disconnect » puisse être diagnostiquée comme une défaillance précise de suspend/resume, pilote, firmware, hub ou gestion d'alimentation.