Testes de estresse de modo de espera moderno e de longa duração

Artigo
06/19/2023

Os designers de sistema devem executar testes de estresse e testes de longa duração nos sistemas de modo de espera moderno para ajudar a identificar e resolver possíveis problemas de confiabilidade. O modo de espera moderno permite que o sistema continue em execução, mesmo quando ele está em um estado de baixo consumo de energia e desativação da tela. Esse estado é diferente dos estados tradicionais ACPI de Suspensão (S3) e Hibernação (S4), nos quais grande parte do hardware e do software do sistema é interrompido e permanece inativo até que seja reiniciado depois na retomada.

O modo de espera moderno permite que o sistema permaneça em funcionamento por um tempo total muito maior e, portanto, pode expor problemas de confiabilidade de hardware e software que não seriam descobertos em um sistema com suporte apenas para S3 e S4.

Entrada e saída

Cada sistema de modo de espera moderno deve ser validado para entrar e sair do modo de espera moderno em pelo menos 1.000 ciclos sem falha. A entrada e a saída do modo de espera moderno é a principal interação do usuário com a operação de baixo consumo de energia no sistema e deve ser extremamente confiável.

A entrada e a saída do modo de espera moderno com êxito valida vários componentes de hardware, firmware e driver do dispositivo, que incluem:

O hardware da plataforma que gerencia a operação do botão de energia, incluindo o PMIC (circuito integrado de gerenciamento de energia).
O hardware de inicialização e gerenciamento do painel de exibição.
O firmware e o driver do dispositivo de rede e de WiFi.
O driver de dispositivo gráfico.

O teste de estresse da entrada e saída do modo de espera moderno pode ser automatizado usando a ferramenta PwrTest. O PwrTest deve ser instalado no sistema de destino como parte do Kit de Driver do Windows (WDK), que inclui software adicional para automatizar o botão de energia do sistema em sistemas de modo de espera moderno.

Cenário de teste	Resultado esperado	Observações de diagnóstico
O sistema pode entrar e sair do modo de espera moderno de forma confiável por pelo menos 1.000 ciclos.	Use a ferramenta PwrTest e a opção de linha de comando /cs para colocar o sistema automaticamente no modo de espera moderno por 1.000 ciclos. O resultado esperado é que o sistema conclua os 1.000 ciclos.	Recomendamos aumentar de modo incremental o teste de estresse até 1.000 ciclos. Primeiro, teste 100 ciclos. Se um erro for encontrado, conecte o sistema a um depurador de kernel e ao depurador de hardware do SOC e repita o teste de 100 ciclos para capturar e determinar a causa raiz do problema. Após a conclusão bem-sucedida do teste de 100 ciclos, estenda a contagem de ciclos para 500 ciclos e depois para 1.000 ciclos.

Transições de estado de baixo consumo de energia do SOC

O firmware e os drivers responsáveis pelo gerenciamento de transições de SOC entre os estados de energia ocioso e ativo devem ser altamente confiáveis para aguentar o estresse de operar em modo de espera moderno por períodos prolongados. As transições de estado de baixo consumo de energia do SOC devem ser estressadas por meio de testes de modo de espera moderno de longa duração. Esse teste ajuda a garantir que o sistema permaneça operacional de modo confiável durante longos períodos no modo de espera moderno, como durante o fim de semana. Esse teste deve ser executado com conexão à energia AC.

Cenário de medição	Resultado esperado	Observações sobre energia
O sistema pode permanecer no modo de espera moderno por 100 horas consecutivas e ainda funcionar na saída. O sistema mantém a conectividade WiFi durante as 100 horas e ela continua funcional na saída.	Coloque o sistema no modo de espera moderno e ative-o com o botão de energia após 100 horas. O resultado esperado é que o sistema se alimente instantaneamente e a conexão Wi-Fi esteja operacional sem configuração adicional ou seleção de uma rede WiFi.	Recomendamos aumentar de modo incremental o teste de longa duração até 100 horas. Primeiro, teste por 24 horas. Se um erro for encontrado, conecte o sistema a um depurador de kernel e ao depurador de hardware do SOC e repita o teste de 24 horas para capturar e determinar a causa raiz do problema. Depois que o teste de 24 horas for concluído com êxito, estenda a duração para 100 horas.

O sistema pode permanecer no modo de espera moderno por 100 horas consecutivas e ainda funcionar na saída. O sistema mantém a conectividade WiFi durante as 100 horas e ela continua funcional na saída.

Coloque o sistema no modo de espera moderno e ative-o com o botão de energia após 100 horas.

O resultado esperado é que o sistema se alimente instantaneamente e a conexão Wi-Fi esteja operacional sem configuração adicional ou seleção de uma rede WiFi.

Recomendamos aumentar de modo incremental o teste de longa duração até 100 horas.

Primeiro, teste por 24 horas. Se um erro for encontrado, conecte o sistema a um depurador de kernel e ao depurador de hardware do SOC e repita o teste de 24 horas para capturar e determinar a causa raiz do problema.

Depois que o teste de 24 horas for concluído com êxito, estenda a duração para 100 horas.

Teste de estresse no modo de espera moderno do Windows HLK

O Windows HLK (Hardware Lab Kit) inclui um teste de estresse de modo de espera moderno chamado estresse de espera conectada com estresse de simultaneidade do verificador de driver que executa transições automáticas de modo de espera moderno ao mesmo tempo em que os drivers de dispositivo são executados para a operação do dispositivo. O teste foi projetado para verificar se o dispositivo e seus drivers continuam funcionando à medida que o sistema faz a transição de/para o estado de energia do modo de espera moderno.

Esse teste é uma parte crítica da validação de que o sistema continua operando conforme o esperado depois de sair do modo de espera moderno. Esse teste está incluído no Windows HLK e é necessário para a certificação do sistema.

Operação de teste

O teste usa as interfaces SimpleIO do WDTF (Windows Device Testing Framework) para exercitar dispositivos que são enumerados no sistema. Esses dispositivos incluem sensores, câmeras, áudio, elementos gráficos, WiFi, armazenamento e Bluetooth. O teste coloca o sistema no modo de espera moderno por um minuto e depois remove o sistema do modo de espera moderno e exercita os dispositivos em 30 segundos. Esse ciclo se repete 150 vezes.

Durante a execução do teste, o verificador de driver é habilitado para ajudar a identificar bugs de driver e perda de memória.

O teste ajuda a identificar os seguintes problemas de sistema ou de driver de dispositivo:

Um sistema fica sem resposta ou falha durante a operação do dispositivo após uma sessão de modo de espera moderno.
A incapacidade do sistema de entrar no estado de baixo consumo de energia (estado mais profundo de ociosidade de runtime da plataforma ou DRIPS) após a atividade do dispositivo.
Problemas de driver identificados pelo verificador de driver, incluindo corrupção do sistema, falhas de driver e perdas de memória.
Problemas de driver após a retomada do modo de espera moderno, incluindo falta de resposta, falhas ou códigos de problema.

Resolver falhas de teste

O teste exercita vários dispositivos, o que pode resultar em diferentes tipos de falhas de teste. A identificação do tipo de falha de teste é a primeira etapa para encontrar a causa raiz dos problemas do sistema ou do driver.

O teste normalmente falha em um dos três seguintes modos de falha:

O teste falha e a falha é registrada nos logs do Windows HLK, que contêm dados sobre a falha detectada.
O teste falha, mas o sistema não se relata ao servidor Windows HLK como resultado da falha. O sistema fica responsivo e funciona com interação local.
O teste não é concluído e o sistema em teste falha ou fica sem resposta (congelado em uma tela preta).

Depurar falhas de teste registradas nos logs do Windows HLK

Há dois tipos de falha comuns quando falhas de teste são registradas nos logs do Windows HLK:

O sistema não pôde entrar no estado de baixo consumo de energia (DRIPS) durante o teste.
O teste detectou que ele não podia mais se comunicar com um driver e o tempo limite foi atingido.

Você pode usar o relatório SleepStudy, que está incluído nos logs de teste, para identificar quais componentes são responsáveis por impedir que o sistema entre no estado de baixo consumo de energia (DRIPS). Há várias causas comuns:

Problemas de instalação e configuração de teste, incluindo o uso de um adaptador Ethernet com fio que não dê suporte ao NDIS 6.3 e à funcionalidade de modo de espera moderno.
Problemas do servidor DHCP na rede LAN com fio.
Um dispositivo e/ou driver que não fique corretamente ocioso no próprio modo de baixo consumo de energia durante o modo de espera moderno.

Os logs de teste também podem incluir uma mensagem de falha indicando quais dispositivos não responderam às solicitações de E/S em tempo hábil. Essa condição é considerada uma falha de teste porque pode impedir que o usuário ou um aplicativo fique funcional quando o sistema é retomado do modo de espera moderno.

Os logs de teste indicam os últimos dispositivos a executar operações de E/S. Esses dispositivos são a origem da falha de teste. A saída do log de teste no exemplo a seguir mostra que o dispositivo ACPI\XXXX\2&DAFA3FF&1 atingiu o tempo limite.

Mensagem	7/16/2013 12:50:24.333 AM	WDTF_SIMPLEIO_STRESS_PROC : - WaitAsyncCompletion(Some Location Sensor Device ACPI\XXXX\2&DAFA3FF&1)
Mensagem	7/16/2013 12:59:50.333 AM	WDTF_SIMPLEIO_STRESS_PROC : - WaitAsyncCompletion(Some Other Device XXX_XXX\UART_XXX\3&2F829BAD&0&F00D)

Uma causa comum de falhas é a recepção ruim de GPS, o que faz com que o dispositivo GPS demore muito tempo para responder às solicitações de E/S. Para obter mais informações de como executar esse teste em sistemas com dispositivos GPS, confira Observações para sistemas equipados com GPS.

Depurar falhas de teste sem logs (e um sistema responsivo)

Se o sistema em teste ainda estiver em execução sem sinais de que o teste ainda está em execução, a causa mais provável será que o sistema encontrou um erro fatal ou foi reiniciado. Para depurar esses problemas, verifique se há arquivos de despejo no diretório do sistema e desabilite qualquer watchdog de hardware que possa redefinir o sistema.

Depurar falhas de teste quando o sistema não responde (tela preta)

Se o sistema estiver congelado em uma tela preta, um depurador de kernel precisará ser conectado ao sistema para diagnosticar o problema.

Se o depurador de kernel já estiver conectado e o sistema não estiver respondendo a ele, um depurador de hardware será necessário para identificar o motivo pelo qual o sistema está bloqueado. Você pode consultar o provedor principal de silício/SOC para obter assistência adicional com a depuração.

Documentação adicional do HLK

Observações para sistemas equipados com GPS

Se o sistema em teste tiver um dispositivo GPS ou um dispositivo de sensor de localização, as seguintes configurações do Windows precisarão ser habilitadas antes da execução do teste:

Painel de Controle\Hardware e Som\Configurações de Localização\Ativar a plataforma de localização do Windows
Configurações do computador\Privacidade\Localização: permitir que o Windows e os aplicativos usem minha localização

Você pode usar a Ferramenta de Diagnóstico de Sensor no Kit de Driver do Windows (WDK) para confirmar a recepção do sinal de GPS no site de teste. Para obter mais informações, confira Testar a funcionalidade do sensor com a ferramenta de diagnóstico de sensor.

Compartilhar via