Pruebas de estrés y larga duración del Modo de espera moderno
Los diseñadores de sistemas deberían realizar pruebas de estrés y pruebas de larga duración en sus sistemas de Modo de espera moderno para ayudar a identificar y resolver posibles problemas de fiabilidad. Modo de espera moderno permite que el sistema siga funcionando, incluso cuando se encuentra en un estado de bajo consumo y con la pantalla apagada. Este estado es diferente de los estados tradicionales de Suspensión ACPI (S3) e Hibernación (S4), en los que gran parte del hardware y software del sistema se detiene y después permanece inactivo hasta que se reinicia más tarde al reanudarse.
Modo de espera moderno permite que el sistema permanezca en funcionamiento durante un tiempo total mucho más prolongado y, por tanto, puede poner al descubierto problemas de fiabilidad de hardware y software que no se descubrirían en un sistema que solo fuera compatible con S3 y S4.
Entrada y salida
Todo sistema de Modo de espera moderno debe ser validado para entrar y salir del Modo de espera moderno durante al menos 1 000 ciclos sin fallos. La entrada y salida del Modo de espera moderno es la interacción principal del usuario con el funcionamiento de bajo consumo del sistema y debe ser extremadamente fiable.
Entrar y salir con éxito del Modo de espera moderno valida una serie de componentes de hardware, firmware y controladores de dispositivos, entre los que se incluyen:
- El hardware de la plataforma que administra el funcionamiento del botón de encendido, incluido el circuito integrado de administración de energía (PMIC).
- El hardware de administración e inicialización del panel de visualización.
- El firmware y el controlador del dispositivo Wi-Fi y de red.
- El controlador del dispositivo gráfico.
Las pruebas de estrés de la entrada y salida del Modo de espera moderno pueden automatizarse usando la herramienta PwrTest. PwrTest debe instalarse en el sistema de destino como parte del Kit de controladores de Windows (WDK), que incluye software adicional para automatizar el botón de encendido del sistema en los sistemas de Modo de espera moderno.
| Escenario de prueba | Resultado esperado | Notas de diagnóstico |
|---|---|---|
El sistema puede Entrar y salir del Modo de espera moderno de forma fiable durante al menos 1 000 ciclos. |
Use la herramienta PwrTest y la opción de línea de comandos /cs para realizar automáticamente un ciclo de espera moderno del sistema durante 1 000 ciclos. El resultado esperado es que el sistema complete los 1 000 ciclos. |
Recomendamos aumentar gradualmente la prueba de esfuerzo hasta 1 000 ciclos. En primer lugar, realice una prueba de 100 ciclos. Si se encuentra un error, conecte el sistema a un depurador de kernel y al depurador de hardware del SoC, y repita la prueba de 100 ciclos para capturar y determinar la causa raíz del problema. Después de completar con éxito la prueba de 100 ciclos, amplíe el recuento de ciclos a 500 ciclos y después a 1 000 ciclos. |
Transiciones de estado de bajo consumo del SoC
El firmware y los controladores responsables de administrar las transiciones del SoC entre los estados de energía de reposo y de actividad deben ser altamente fiables para soportar las exigencias de funcionar durante largos periodos en Modo de espera moderno. Las transiciones de estado de bajo consumo del SoC deben someterse a pruebas mediante pruebas de Modo de espera moderno de larga duración. Estas pruebas garantizan que el sistema siga funcionando de forma fiable durante los largos periodos de Modo de espera moderno, como por ejemplo durante el fin de semana. Esta prueba debe realizarse mientras esté conectado a la corriente alterna.
| Escenario de medición | Resultado esperado | Notas de energía |
|---|---|---|
El sistema puede permanecer en Modo de espera moderno durante 100 horas consecutivas y es funcional al salir. El sistema mantiene la conectividad Wi-Fi durante las 100 horas y la conectividad Wi-Fi es funcional al salir. |
Ponga el sistema en Modo de espera moderno y despiértelo con el botón de encendido después de 100 horas. El resultado esperado es que el sistema se encienda al instante y la conexión Wi-Fi esté operativa sin necesidad de configuración adicional ni de seleccionar una red Wi-Fi. |
Recomendamos aumentar progresivamente la prueba de larga duración a 100 horas. En primer lugar, realice una prueba durante 24 horas. Si se encuentra un error, conecte el sistema a un depurador de kernel y al depurador de hardware del SoC, y repita la prueba de 24 horas para capturar y determinar la causa raíz del problema. Una vez finalizada con éxito la prueba de 24 horas, amplíe la duración a 100 horas. |
Prueba de estrés del Modo de espera moderno de Windows HLK
El Kit de laboratorio de hardware de Windows (HLK) incluye una prueba de estrés del Modo de espera moderno denominada Estrés de modo de espera conectado con Estrés de simultaneidad del Comprobador de controladores que ejercita las transiciones automáticas del Modo de espera moderno al mismo tiempo que se ejercitan los controladores de funcionamiento de los dispositivos. La prueba está diseñada para verificar que el dispositivo y su(s) controlador(es) siguen funcionando cuando el sistema entra y sale del estado de energía Modo de espera moderno.
Esta prueba es una parte fundamental para validar que el sistema sigue funcionando como se esperaba después de salir del Modo de espera moderno. Esta prueba se incluye como parte del HLK de Windows y es necesaria para la certificación del sistema.
Probar operación
La prueba usa las interfaces de SimpleIO del marco de pruebas de dispositivos de Windows (WDTF) para ejercitar los dispositivos enumerados en el sistema. Estos dispositivos incluyen sensores, cámaras, dispositivos de audio, gráficos, Wi-Fi, de almacenamiento y Bluetooth. La prueba coloca el sistema en Modo de espera moderno durante un minuto, y después lo saca del Modo de espera moderno y ejercita los dispositivos durante 30 segundos. Este ciclo se repite 150 veces.
Durante la ejecución de la prueba, se habilita Comprobador de controladores para ayudar a identificar los errores del controlador y las fugas de memoria.
La prueba ayuda a identificar los siguientes problemas del sistema o del controlador del dispositivo:
- Un sistema deja de responder o se bloquea durante el funcionamiento del dispositivo después de una sesión de Modo de espera moderno.
- La incapacidad del sistema para entrar en el estado de bajo consumo (estado de plataforma inactiva en tiempo de ejecución más profundo o DRIPS) tras la actividad del dispositivo.
- Los problemas de los controladores identificados por el Comprobador de controladores, incluidos la corrupción del sistema, los fallos de los controladores y las fugas de memoria.
- Problemas con los controladores después de reanudar el Modo de espera moderno, incluyendo falta de respuesta, bloqueos o códigos de problemas.
Resolución de fallos en las pruebas
La prueba ejercita múltiples dispositivos, lo que puede dar lugar a diferentes tipos de fallos en la prueba. Identificar el tipo de fallo de la prueba es el primer paso para encontrar la causa raíz de los problemas del sistema o del controlador.
La prueba suele fallar en uno de los tres modos de fallo siguientes:
- La prueba falla y el fallo se registra en los registros del HLK de Windows, que contienen datos sobre el fallo detectado.
- La prueba falla, pero el sistema no informa al servidor del HLK de Windows como resultado del fallo; sin embargo, el sistema responde y funciona con interacción local.
- La prueba no se completa y el sistema bajo prueba se bloquea o deja de responder (se congela en una pantalla negra).
Depuración de los fallos de las pruebas que se registran en los registros del HLK de Windows
Existen dos tipos de fallos comunes cuando se registran los fallos de las pruebas en los registros del HLK de Windows:
- El sistema no pudo entrar en el estado de bajo consumo (DRIPS) durante la prueba.
- La prueba detectó que ya no podía comunicarse con un controlador y se agotó el tiempo de espera.
Puede usar el informe SleepStudy, que se incluye como parte de los registros de la prueba, para identificar qué componentes son los responsables de evitar que el sistema entre en el estado de bajo consumo (DRIPS). Existen varias causas comunes:
- Compruebe los problemas de instalación y configuración, incluido el uso de un adaptador Ethernet por cable que no sea compatible con NDIS 6.3 y la funcionalidad del Modo de espera moderno.
- Problemas con el servidor DHCP en la red LAN cableada.
- Un dispositivo y/o controlador que no pasa correctamente a su propio modo de bajo consumo durante el Modo de espera moderno.
Los registros de las pruebas también pueden incluir un mensaje de fallo que indique qué dispositivos no respondieron a las solicitudes de E/S en el momento oportuno. Esta condición se considera un fallo de prueba porque puede impedir que el usuario o una aplicación sean funcionales cuando el sistema se reanude desde el Modo de espera moderno.
Los registros de la prueba indican los últimos dispositivos que realizaron operaciones de E/S: estos dispositivos son el origen del fallo de la prueba. La salida del registro de prueba en el siguiente ejemplo muestra que el dispositivo ACPIXXXX2&DAFA3FF&1 agotó el tiempo de espera.
Message |
16/7/2013 12:50:24.333 AM |
WDTF_SIMPLEIO_STRESS_PROC : - WaitAsyncCompletion(Some Location Sensor Device ACPI\XXXX\2&DAFA3FF&1) |
Message |
16/7/2013 12:59:50.333 AM |
WDTF_SIMPLEIO_STRESS_PROC : - WaitAsyncCompletion(Some Other Device XXX_XXX\UART_XXX\3&2F829BAD&0&F00D) |
Una causa común de fallos es la mala recepción del GPS, que hace que el dispositivo GPS tarde muchísimo tiempo en responder a las solicitudes de E/S. Para más información sobre la ejecución de esta prueba en sistemas con dispositivos GPS, consulte Notas para sistemas equipados con GPS.
Depuración de fallos de pruebas sin registros (y un sistema que responde)
Si el sistema sometido a prueba sigue funcionando sin signos de que la prueba se esté ejecutando, la causa más probable es que el sistema haya encontrado un error fatal o se haya reiniciado. Para depurar estos problemas, compruebe si hay archivos de volcado en el directorio del sistema y desactive cualquier guardián de hardware que pueda reiniciar el sistema.
Depuración de fallos de pruebas cuando el sistema no responde (pantalla negra)
Si el sistema se congela en una pantalla negra, debe conectarse un depurador del kernel al sistema para diagnosticar el problema.
Si el depurador del kernel ya está conectado y el sistema no responde al depurador del kernel, se requiere un depurador de hardware para identificar la razón por la que el sistema se bloquea. Puede consultar con el proveedor del núcleo de silicio/SoC para obtener ayuda adicional con la depuración.
Documentación adicional del HLK
Notas para los sistemas equipados con GPS
Si el sistema sometido a prueba dispone de un dispositivo GPS o de un dispositivo sensor de ubicación, antes de ejecutar la prueba deberá activar los siguientes ajustes de Windows:
- Panel de control\NHardware y sonido\Configuración de ubicación\Activar la Plataforma de ubicación de Windows
- Configuración de PC\Privacidad\Ubicación: Permitir que Windows y las aplicaciones usen mi ubicación
Puede usar la Herramienta de diagnóstico de sensores del Kit de controladores de Windows (WDK) para confirmar la recepción de la señal GPS en el lugar de la prueba. Para más información, consulte Comprobación de la funcionalidad del sensor con la Herramienta de diagnóstico de sensores.