Depuração de USB Selective Suspend: desconexões aleatórias, falhas de sleep/resume e transferências faltando

O USB selective suspend existe para economizar energia. Quando funciona, dispositivos em idle entram em estado de baixo consumo e voltam quando preciso. Quando falha, o usuário vê desconexões aleatórias, dados faltando, câmeras travadas, portas seriais que param de responder, dispositivos HID que perdem entrada, ou dispositivos que somem depois do sleep. Buscas como "USB selective suspend random disconnect", "USB device stops working after idle", "USB resume failure" e "disable USB selective suspend" geralmente vêm de gente que já trocou cabo e driver.

Desligar o selective suspend pode ser um workaround, mas não é diagnóstico. A pergunta real é se o dispositivo, driver, hub, host controller ou aplicação está falhando durante o suspend/resume ou na recuperação de idle.

O Bus Scope ajuda porque a falha tem uma linha do tempo. Você precisa saber qual tráfego aconteceu antes do idle, se o host suspendeu o caminho, qual requisição acordou o dispositivo, e qual transferência falhou depois do resume.

O que o selective suspend faz

O selective suspend permite que o sistema operacional suspenda um dispositivo ou interface USB individual enquanto o resto do sistema continua ativo. Isso é diferente de sleep completo do sistema. Um dispositivo USB pode ser suspenso porque parece ocioso mesmo com o computador ligado.

Isso importa para:

• adaptadores seriais USB
• dispositivos HID
• câmeras USB
• interfaces de áudio
• probes de debug
• tokens de segurança
• dispositivos vendor customizados
• sensores alimentados pelo barramento

Se o firmware do dispositivo não tratar suspend/resume corretamente, a primeira transferência depois do idle pode falhar.

Sintomas típicos

Problemas de selective suspend costumam aparecer como:

• Dispositivo funciona logo após conectar, mas falha depois de alguns minutos.
• Primeiro comando depois do idle dá timeout.
• Leitura serial trava para sempre depois de inatividade.
• Preview da câmera trava depois da tela bloquear.
• Relatórios HID param até tirar e recolocar o cabo.
• Dispositivo reconecta com um novo endereço.
• Aplicação diz que o dispositivo desconectou, mas ele continua fisicamente conectado.
• Logs do Windows ou do Linux mostram mensagens de reset ou resume.

O padrão-chave é tempo. Se a falha segue períodos de idle, sleep/resume, tela desligada ou mudança de estado de energia do notebook, o gerenciamento de energia entra na investigação.

Falha de suspend versus falha de resume

São dois problemas diferentes:

• Falha de suspend: o dispositivo ou driver não consegue entrar em baixo consumo corretamente.
• Falha de resume: o dispositivo entra em baixo consumo, mas não volta corretamente.

Da perspectiva do usuário, os dois podem parecer "dispositivo desconectou". O trace USB consegue separar mostrando se o tráfego parou de forma limpa e se a próxima requisição depois do idle falhou.

Se o dispositivo desaparece só depois que a aplicação envia um comando após o idle, suspeite de resume ou restauração de estado no firmware. Se o dispositivo reseta enquanto está em idle sem nenhuma requisição da aplicação, suspeite de gerenciamento de energia do host, comportamento do hub ou watchdog do firmware do dispositivo.

Primeira transferência depois do idle

A primeira transferência depois do idle costuma ser a evidência mais importante. Ela pode ser:

• Uma requisição de controle.
• Uma leitura ou escrita bulk.
• Um poll interrupt IN.
• Uma requisição específica de classe.
• Um comando vendor.
• Uma requisição de restart de stream.

Se essa primeira transferência dá timeout, trava ou dispara reset, provavelmente o dispositivo não voltou ao estado esperado. A correção pode estar no tratamento de resume do firmware, na política de energia do driver, no retry da aplicação ou no selective suspend desabilitado para aquele dispositivo.

Runtime power management no Linux

O Linux também tem runtime power management USB. Dispositivos podem entrar em autosuspend depois de um delay de idle. Um dispositivo pode se comportar diferente dependendo do driver, da versão do kernel, das configurações de autosuspend e de se uma aplicação mantém o dispositivo aberto.

Para investigar no Linux, capture o tráfego e correlacione com os logs do sistema. Se o dispositivo resume e reseta imediatamente, o trace do barramento é mais útil do que um "I/O error" genérico vindo da aplicação.

Selective suspend no Windows

No Windows, o comportamento do selective suspend depende do plano de energia, do suporte do driver, das configurações do hub USB e da classe do dispositivo. Usuários frequentemente desativam a "USB selective suspend setting" nas opções de energia. Isso pode ser um workaround prático, mas um diagnóstico profissional ainda deve explicar se o dispositivo falhou durante a recuperação de idle.

Problemas de USB no Windows também podem ser afetados por Modern Standby, comportamento de dock de notebook, hubs e drivers de host controller. Um dispositivo pode funcionar em um desktop e falhar no dock de um notebook porque o comportamento de suspend e resume é diferente.

Estratégia de captura

Para capturar um bug de selective suspend:

1. Comece a captura enquanto o dispositivo está funcionando.
2. Execute uma operação que normalmente dá certo.
3. Deixe o dispositivo em idle o tempo suficiente para disparar o problema.
4. Execute a operação que costuma falhar.
5. Continue a captura através do timeout, reset ou reconexão.
6. Salve a janela inteira de tempo.

Não comece a captura só depois que o dispositivo já falhou. Você precisa da transição de ativo para idle até a falha.

O que procurar no trace

No trace, inspecione:

• Última transferência antes do idle.
• Intervalo de tempo até a falha.
• Primeira transferência depois do idle.
• Timeout, stall, reset ou desconexão.
• Reenumeração depois da falha.
• Mudança no endereço do dispositivo.
• Requisição específica de classe depois do resume.
• Recuperação de halt em endpoint.
• Mudanças de alternate setting para dispositivos de streaming.

Timing não é ruído aqui. Timing é a evidência.

Checklist de depuração

Use esta ordem:

1. Confirme se as falhas se correlacionam com idle.
2. Teste em energia AC e em bateria.
3. Teste porta direta versus hub ou dock.
4. Capture antes do idle e através da falha.
5. Identifique a primeira transferência que falhou depois do idle.
6. Confira se o dispositivo reseta ou só uma transferência falha.
7. Compare com selective suspend desativado.
8. Compare com outro SO ou host controller.
9. Confira o tratamento de resume do firmware.
10. Confira a política de energia do driver e o comportamento de retry da aplicação.

Diagnóstico final

Problemas de USB selective suspend não se resolvem bem com achismo. Desativar o gerenciamento de energia pode reduzir sintomas, mas a resposta real de engenharia vem da linha do tempo USB: tráfego ativo, gap de idle, tentativa de resume, transferência que falhou, reset ou recuperação.

O Bus Scope ajuda a preservar e inspecionar essa evidência para que uma "desconexão aleatória de USB" possa ser diagnosticada como uma falha específica de suspend/resume, driver, firmware, hub ou gerenciamento de energia.