Débogage du remote wakeup et du suspend/resume USB

Les bugs de gestion d'alimentation USB sont durs à diagnostiquer car le périphérique peut fonctionner parfaitement quand le système est actif et échouer seulement après inactivité, veille, selective suspend, veille du dock, fermeture du capot d'un laptop ou extinction du moniteur. Les utilisateurs cherchent « USB remote wakeup not working », « USB selective suspend disconnect », « USB device does not wake computer », « USB resume failure », « USB suspend resume bug » ou « HID keyboard wake from sleep not working ».

Bus Scope est utile car suspend et resume sont des événements au niveau bus, pas seulement des erreurs applicatives. Vous devez voir si l'hôte a suspendu le périphérique, si le remote wakeup a été activé, si le périphérique a signalé le resume, si l'hôte a repris le trafic, et si le périphérique s'est ré-énuméré au lieu de resume.

Ce que signifie remote wakeup

Le remote wakeup permet à un périphérique USB suspendu de demander à l'hôte de reprendre la communication. Exemples courants :

• Un clavier réveille un desktop en veille.
• Une souris réveille un laptop depuis l'inactivité.
• Un bouton de dock réveille une station de travail.
• Un scanner de codes-barres réveille une borne.
• Un contrôleur industriel réveille un panel PC.
• Un capteur HID réveille un hôte après un événement externe.

Le remote wakeup n'est pas simplement « le périphérique a du courant ». L'hôte doit l'autoriser, le périphérique doit annoncer le support, la feature doit être activée, et la signalisation de resume doit arriver au bon moment.

Symptômes courants

Les problèmes de remote wakeup et suspend ressemblent à :

• Le périphérique marche jusqu'à ce que le PC se mette en veille.
• Le périphérique ne réveille pas l'ordinateur.
• Le périphérique réveille le système immédiatement après le suspend.
• Le périphérique disparaît après le resume.
• Le périphérique se ré-énumère avec une nouvelle adresse.
• Entrée HID manquée après inactivité.
• Périphérique série arrête d'émettre après selective suspend.
• Périphérique audio ou caméra revient de veille sans données.
• Le firmware ne récupère qu'après débranchement/rebranchement.

Ces symptômes sont souvent mis sur le compte des pilotes, mais la capture peut montrer un problème d'état d'alimentation firmware.

Preuve de descripteur et de feature

Le descripteur de configuration peut annoncer la capacité remote wakeup. L'hôte peut ensuite activer ou désactiver la feature remote wakeup. Une bonne trace diagnostique USB doit répondre à :

• Le périphérique annonce-t-il le remote wakeup ?
• L'hôte a-t-il envoyé SET_FEATURE(DEVICE_REMOTE_WAKEUP) ?
• L'hôte a-t-il clear la feature ensuite ?
• Le suspend s'est-il produit après inactivité ?
• Le périphérique a-t-il tenté la signalisation de resume ?
• L'hôte a-t-il repris les transferts normaux ?

Sans ces faits, le diagnostic est du tâtonnement.

Selective suspend

La selective suspend permet au système d'exploitation de suspendre un périphérique USB inactif sans mettre tout le système en veille. Cela économise de l'énergie, mais cela expose des bugs firmware.

Motifs de défaillance :

• Le périphérique entre en low-power mais ne restaure pas l'état de l'endpoint.
• Le firmware perd l'état interrupt IN en attente.
• Le périphérique NAKe pour toujours après resume.
• L'hôte reset le périphérique après timeout.
• L'application voit un timeout ou un retrait de périphérique.
• Le périphérique composite resume une interface mais pas une autre.

Les chercheurs tapent souvent « USB selective suspend random disconnect » car le périphérique semble se déconnecter alors que l'événement réel est un échec de suspend/resume.

Resume vs ré-énumération

Après la veille, il y a deux issues très différentes :

• Resume : le même périphérique continue avec la configuration existante.
• Ré-énumération : l'hôte reset et ré-énumère le périphérique.

La ré-énumération peut être acceptable après une déconnexion physique, mais elle est suspecte après un suspend normal. Elle peut casser les applications qui détiennent des handles, des noms de ports série, des chemins HID ou des sessions de capture caméra.

Bus Scope doit aider à identifier si la trace contient un trafic de resume normal ou une nouvelle séquence d'énumération avec GET_DESCRIPTOR, SET_ADDRESS et SET_CONFIGURATION.

Wake events manqués

Parfois le périphérique voit l'événement externe mais l'hôte ne se réveille pas. Causes :

• Remote wakeup non annoncé.
• Remote wakeup non activé par l'hôte.
• Le périphérique envoie le resume trop tôt.
• Le périphérique envoie le resume trop tard.
• Le hub bloque ou mal gère la signalisation de wake.
• La politique de wake du BIOS ou de l'OS désactive le port.
• Le firmware du périphérique entre dans un sommeil plus profond qu'attendu.
• L'événement survient avant que le suspend ne soit terminé.

La preuve au niveau paquet ne remplace pas la politique d'alimentation de l'OS, mais elle cernera la question. Le périphérique avait-il la permission de réveiller l'hôte, et a-t-il essayé ?

Wake immédiat après suspend

Le problème opposé est aussi courant : le système suspend et se réveille immédiatement. Les périphériques USB peuvent causer cela quand ils signalent le wake à cause d'une entrée stale, d'un état d'interrupt bruité, de bugs de debounce, ou d'un firmware qui traite le suspend comme un nouvel événement.

Preuves à collecter :

• Dernier rapport d'interrupt avant suspend.
• Si l'hôte a activé le wake.
• Timing entre suspend et resume.
• Class et interface du périphérique.
• Si le même endpoint avait des données en attente.
• Si l'événement se répète à chaque tentative de suspend.

C'est particulièrement fréquent avec les claviers, souris, panneaux tactiles, manettes et périphériques HID personnalisés.

Checklist de débogage

Suivez ce processus :

1. Capturez l'énumération depuis le branchement.
2. Confirmez la capacité remote wakeup dans les descripteurs.
3. Vérifiez si l'hôte active le remote wakeup.
4. Enregistrez la période d'inactivité avant le suspend.
5. Identifiez le timing du suspend.
6. Cherchez la signalisation de resume ou le trafic de resume de l'hôte.
7. Séparez le resume de la ré-énumération complète.
8. Vérifiez le comportement des endpoints après resume.
9. Comparez le même périphérique sur port direct et via un hub.
10. Conservez les paquets pré-suspend et post-resume.

Diagnostic final

Les bugs de remote wakeup et suspend/resume USB sont des problèmes de protocole d'état d'alimentation. La preuve utile est la capacité de descripteur, la sélection de feature par l'hôte, le timing du suspend, la signalisation de resume, la récupération des endpoints, et si l'hôte a resume ou ré-énuméré le périphérique.

Bus Scope aide à rendre cette preuve visible pour que « USB wake not working » devienne un diagnostic concret au lieu d'une boucle de blâme sur les pilotes.