Modern Standby: Belastungs- und Dauertests

Artikel
06/19/2023

Systemdesigner sollten Belastungs- und Dauertests auf ihren Modern Standby-Systemen ausführen, um potenzielle Zuverlässigkeitsprobleme zu identifizieren und zu beheben. Modern Standby ermöglicht es, das System weiter auszuführen, auch wenn es sich im Energiesparmodus befindet und der Bildschirm ausgeschaltet ist. Dieser Zustand unterscheidet sich von den traditionellen ACPI-Modi Standby (S3) und Ruhezustand (S4), in denen viele Komponenten der Systemhardware und -software beendet und dann inaktiv bleiben, bis sie später neu gestartet werden.

Mit Modern Standby kann das System insgesamt viel länger in Betrieb bleiben und somit Zuverlässigkeitsprobleme bei Hardware und Software aufdecken, die bei einem System, das nur S3 und S4 unterstützt, nicht entdeckt werden würden.

Starten und Beenden

Für jedes Modern Standby-System muss sichergestellt sein, dass es mindestens 1.000 Zyklen lang fehlerfrei in den und aus dem Modern Standby-Modus wechseln kann. Der Wechsel in den und aus dem Modern Standby ist die wesentliche Interaktion des Benutzers mit dem Energiesparmodus des Systems und muss daher besonders zuverlässig sein.

Beim erfolgreichen Aufrufen und Beenden von Modern Standby wird eine Reihe von Hardware-, Firmware- und Gerätetreiberkomponenten wie die folgenden geprüft:

Die Plattformhardware, die den Netzschalterbetrieb verwaltet, einschließlich des Power-Management-IC (PMIC).
Die Hardware für die Anzeigefeldverwaltung und -initialisierung.
Die Firmware und der Treiber für WLAN- und Netzwerkgeräte.
Der Grafikkartentreiber.

Belastungstests für das Ein- und Ausschalten von Modern Standby können mithilfe von PwrTest automatisiert werden. PwrTest wird auf dem Zielsystem als Teil des Windows Driver Kit (WDK) installiert, das zusätzliche Software für die Automatisierung der Systemeinschalttaste auf Modern Standby-Systemen enthält.

Testszenario	Erwartetes Ergebnis	Diagnoseanmerkung
Das System kann Modern Standby zuverlässig für mindestens 1.000 Zyklen starten und beenden.	Verwenden Sie das PwrTest-Tool und die Befehlszeilenoption /cs, um das System automatisch über Modern Standby für 1.000 Zyklen zu testen. Das gewünschte Ergebnis ist, dass das System alle 1.000 Zyklen durchläuft.	Es wird empfohlen, den Belastungstest schrittweise auf 1.000 Zyklen zu erhöhen. Führen Sie zunächst 100 Zyklen durch. Wenn ein Fehler gefunden wird, verbinden Sie das System mit einem Kerneldebugger und dem SoC-Hardwaredebugger, und wiederholen Sie den Test für 100 Zyklen, um die Ursache des Problems zu erfassen und zu ermitteln. Nach erfolgreichem Abschluss des Tests mit 100 Zyklen erhöhen Sie die Anzahl auf 500 und dann auf 1.000 Zyklen.

SoC-Übergänge in den und aus dem Energiesparmodus

Die Firmware und Treiber, die für die Verwaltung von SoC-Übergängen zwischen den Leerlauf- und aktiven Energiezuständen verantwortlich sind, müssen sehr zuverlässig sein, um der Betriebsbelastung für lange Zeiträume in Modern Standby Stand zu halten. SoC-Übergänge in den und aus dem Energiesparmodus sollten durch Dauertests in Modern Standby belastet werden. Dadurch wird sichergestellt, dass das System auch bei langen Modern Standby-Zeiten, z. B. am Wochenende, zuverlässig funktioniert. Für diesen Test muss das Gerät an das Stromnetz angeschlossen sein.

Messungsszenario	Erwartetes Ergebnis	Ausführungshinweise
Das System kann 100 Stunden ununterbrochen in Modernem Standby bleiben und ist beim Beenden des Modus funktionsfähig. Das System hält die WLAN-Verbindung während der 100 Stunden aufrecht, und die WLAN-Verbindung funktioniert auch noch nach dem Beenden.	Setzen Sie das System in den Modern Standby-Modus, und beenden Sie diesen nach 100 Stunden über die Einschalttaste. Das erwartete Ergebnis ist, dass sich das System sofort einschaltet und die WLAN-Verbindung ohne zusätzliche Konfiguration oder Auswahl eines WLAN-Netzwerks betriebsbereit ist.	Es wird empfohlen, den Dauertest schrittweise auf 100 Stunden zu erhöhen. Führen Sie den Test zunächst 24 Stunden durch. Wenn ein Fehler gefunden wird, verbinden Sie das System mit einem Kerneldebugger und dem SoC-Hardwaredebugger, und wiederholen Sie den Test für 24 Stunden, um die Ursache des Problems zu erfassen und zu ermitteln. Nachdem der 24-stündige Test erfolgreich abgeschlossen wurde, verlängern Sie die Dauer auf 100 Stunden.

Das System kann 100 Stunden ununterbrochen in Modernem Standby bleiben und ist beim Beenden des Modus funktionsfähig. Das System hält die WLAN-Verbindung während der 100 Stunden aufrecht, und die WLAN-Verbindung funktioniert auch noch nach dem Beenden.

Setzen Sie das System in den Modern Standby-Modus, und beenden Sie diesen nach 100 Stunden über die Einschalttaste.

Das erwartete Ergebnis ist, dass sich das System sofort einschaltet und die WLAN-Verbindung ohne zusätzliche Konfiguration oder Auswahl eines WLAN-Netzwerks betriebsbereit ist.

Es wird empfohlen, den Dauertest schrittweise auf 100 Stunden zu erhöhen.

Führen Sie den Test zunächst 24 Stunden durch. Wenn ein Fehler gefunden wird, verbinden Sie das System mit einem Kerneldebugger und dem SoC-Hardwaredebugger, und wiederholen Sie den Test für 24 Stunden, um die Ursache des Problems zu erfassen und zu ermitteln.

Nachdem der 24-stündige Test erfolgreich abgeschlossen wurde, verlängern Sie die Dauer auf 100 Stunden.

Modern Standby-Belastungstest von Windows HLK

Das Windows Hardware Lab Kit (HLK) enthält einen Modern Standby-Belastungstest namens „Connected Standby Stress with Driver Verifier's Concurrency Stress“ (Belastung im verbundenen Standby mit Gleichzeitigkeitsbelastung des Treibers), der automatische Modern Standby-Übergänge zur gleichen Zeit wie die Gerätetreiber für den Gerätebetrieb prüft. Mit dem Test wird überprüft, ob das Gerät und zugehörige Treiber weiterhin funktionieren, wenn das System in den und aus dem Modern Standby-Energiesparmodus wechselt.

Dieser Test ist ein entscheidender Teil der Überprüfung, ob das System nach Beendigung des Modern Standby-Modus weiterhin wie erwartet funktioniert. Dieser Test ist fester Bestandteil des Windows HLK und wird für die Systemzertifizierung benötigt.

Vorgang testen

Der Test verwendet die SimpleIO-Schnittstellen des Windows Device Testing Framework (WDTF) zur Überprüfung von Geräten, die auf dem System aufgeführt werden. Zu diesen Geräten gehören Sensoren, Kameras, Audiogeräte, Grafikkarten sowie WLAN-, Speicher- und Bluetooth-Geräte. Bei diesem Test wird das System eine Minute lang in den Modern Standby-Modus versetzt. Anschließend wird der Modern Standby-Modus beendet und die Geräte werden 30 Sekunden lang getestet. Dieser Zyklus wird 150 Mal wiederholt.

Während der Testausführung ist die Treiberüberprüfung aktiviert, um Treiberfehler und Speicherlecks zu identifizieren.

Der Test hilft, die folgenden System- oder Gerätetreiberprobleme zu erkennen:

Nach einer Modern Standby-Sitzung reagiert ein System nicht mehr oder stürzt während des Gerätebetriebs ab.
Die Unfähigkeit des Systems, nach einer Geräteaktivität in den Energiesparmodus (Deepest Runtime Idle Platform State oder DRIPS) zu wechseln.
Treiberprobleme, die bei der Treiberüberprüfung identifiziert werden, einschließlich Systembeschädigungen, Treiberfehlern und Speicherlecks.
Treiberprobleme beim Fortsetzen nach dem Modern Standby-Modus, einschließlich keine Reaktion, Abstürze oder Problemcodes.

Beheben von Testfehlern

Bei dem Test werden mehrere Geräte getestet, wodurch unterschiedliche Arten von Testfehlern auftreten können. Die Identifizierung der Art des Testfehlers ist der erste Schritt, um die Ursache von System- oder Treiberproblemen zu ermitteln.

Der Test schlägt in der Regel in einem der folgenden drei Fehlermodi fehl:

Der Test schlägt fehl, und der Fehler wird in den Windows HLK-Protokollen aufgezeichnet, die Daten über den erkannten Fehler enthalten.
Der Test schlägt fehl, aber das System meldet den Fehler nicht an den Windows HLK-Server. Das System reagiert weiterhin und funktioniert bei lokaler Interaktion.
Der Test wird nicht abgeschlossen, und das zu testende System stürzt ab oder reagiert nicht mehr (eingefroren auf einem schwarzen Bildschirm).

Debuggen von in den Windows HLK-Protokollen aufgezeichneten Testfehlern

Es gibt zwei häufige Fehlertypen, wenn Testfehler in den Windows HLK-Protokollen aufgezeichnet werden:

Das System konnte während des Tests nicht in den Energiesparmodus (DRIPS) wechseln.
Beim Test war die Kommunikation mit einem Treiber nicht mehr möglich, und es kam zu einem Timeout.

Anhand des SleepStudy-Berichts, der in den Testprotokollen enthalten ist, können Sie feststellen, aufgrund welcher Komponenten das System nicht in den Energiesparmodus (DRIPS) versetzt wird. Es gibt mehrere häufige Ursachen:

Probleme bei der Einrichtung und Konfiguration des Tests, z. B. die Verwendung eines kabelgebundenen Ethernetadapters, der NDIS 6.3 und die Modern Standby-Funktionalität nicht unterstützt.
DHCP-Serverprobleme im kabelgebundenen LAN-Netzwerk.
Ein Gerät und/oder ein Treiber, das bzw. der im Modern Standby-Modus nicht ordnungsgemäß in seinen Energiesparmodus übergeht.

Auch die Testprotokolle können eine Fehlermeldung enthalten, die angibt, welche Geräte nicht rechtzeitig auf E/A-Anforderungen reagierten. Dieser Zustand wird als Testfehler betrachtet, da er dazu führen kann, dass Benutzer*innen oder eine Anwendung nicht mehr interagieren können, wenn das System den Modern Standby-Modus beendet.

Die Testprotokolle geben die letzten Geräte an, die E/A-Vorgänge ausführen – diese Geräte sind die Quelle des Testfehlers. Die Testprotokollausgabe im folgenden Beispiel zeigt, dass für das Gerät ACPI\XXXX\2&DAFA3FF&1 ein Timeout vorliegt.

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

Eine häufige Ursache für Fehler ist ein schlechter GPS-Empfang, der dazu führt, dass das GPS-Gerät extrem lange Zeit benötigt, um auf E/A-Anforderungen zu antworten. Weitere Informationen zum Ausführen dieses Tests auf Systemen mit GPS-Geräten finden Sie unter den Hinweise zu Systemen, die mit GPS ausgestattet sind.

Debuggen von Testfehlern ohne Protokolle (und ein reaktionsfähiges System)

Wenn das zu prüfende System noch ausgeführt wird, ohne dass es ersichtlich ist, dass der Test noch läuft, ist höchstwahrscheinlich ein schwerwiegender Fehler aufgetreten oder das System wurde neu gestartet. Zum Debuggen dieser Fehler suchen Sie im Systemverzeichnis nach Dumpdateien und deaktivieren Sie alle Hardwarewatchdogs, die das System neu starten könnten.

Debuggen von Testfehlern, wenn das System nicht mehr reagiert (schwarzer Bildschirm)

Wenn das System auf einem schwarzen Bildschirm eingefroren ist, muss ein Kerneldebugger mit dem System verbunden sein, um das Problem zu diagnostizieren.

Wenn der Kerneldebugger bereits verbunden ist und das System auf diesen nicht reagiert, ist ein Hardwaredebugger erforderlich, um herauszufinden, warum das System gesperrt wird. Sie können sich an den Core-Silicon-/SoC-Anbieter wenden, um Unterstützung beim Debuggen zu erhalten.

Zusätzliche HLK-Dokumentation

Hinweise zu Systemen mit GPS

Wenn das zu prüfende System über ein GPS-Gerät oder einen Positionssensor verfügt, müssen vor der Durchführung des Tests die folgenden Windows-Einstellungen aktiviert werden:

Systemsteuerung\Hardware und Sound\Standorteinstellungen\Plattform für Windows-Position aktivieren
PC-Einstellungen\Datenschutz\Standort: Windows und Apps die Verwendung meines Standorts erlauben

Sie können das Sensordiagnosetool im Windows Driver Kit (WDK) verwenden, um den Empfang des GPS-Signals am Teststandort zu prüfen. Weitere Informationen finden Sie unter Testen der Sensorfunktionalität mit dem Sensordiagnosetool.

Freigeben über