UE-Hangerkennung: Schritte 1-14
Die Schritte 1 bis 14 der UE-Hangerkennung werden unten beschrieben. Die Schritte entsprechen dem Diagramm, das unter UE-Hangerkennung und -Wiederherstellungsablauf dargestellt ist.
In diesem Beispiel wird OID_SET_POWER verwendet.
NDIS empfängt eine Systemleistungs-IRP, oder die aktiven NIC-Verweise fallen auf 0.
NDIS generiert eine OID_SET_POWER D3 für den WDI-Treiber.
WDI legt einen Timer für einen WDI-Befehl (M1) fest, einschließlich einer Aufgabe, bevor die WDI-OID an die LE gesendet wird. Wenn der Befehl eine Aufgabe ist, wird auch ein zusätzlicher Timer für die Aufgabe festgelegt. Beide Timer können ein Timeout ausführen, aber höchstens einer kann eine Wiederherstellung auslösen.
WDI sendet den WDI-Befehl an die LE. Die Empfehlung für die LE besteht darin, sich die WDI-OID in der Adapterstruktur zu merken, wenn sie einen Firmwarebefehl benötigt, um die OID abzuschließen. Wenn die Firmware den Auftrag für die WDI-OID abgeschlossen hat, schließt die LE die OID ab und entfernt sie aus der Adapterstruktur. Da WDI OIDs in die LE serialisiert, benötigt die LE nur einen Steckplatz, um sich die ausstehende WDI-OID zu merken. Wenn der Firmwarebefehl aufgehängt wird, kann die LE die OID jederzeit zurückgeben, aber spätestens bei surprise-remove (er kann im Kontext von surprise-remove) in Schritt 17 zurückgegeben werden, wenn die Firmware deaktiviert wurde. In anderen Fällen schließt die LE einfach die WDI-OID ab, wenn die Firmware den entsprechenden Auftrag abgeschlossen hat, unabhängig davon, ob sie vor oder nach einem Diagnoserückruf erfolgt. Wenn sich die LE nach der Diagnose an die WDI-OID erinnern muss, benötigt sie einen anderen Steckplatz, um sich dies zu merken. Für die nach der Diagnose empfangenen OIDs sollte die LE die Firmware jedoch nicht berühren, um kaskadierte Hänger zu vermeiden.
Die LE sendet einen Befehl an die Firmware.
Wenn für den Firmwarebefehl ein Timeout eintritt, kann dies darauf zurückzuführen sein, dass eine Firmware hängt oder zu lange dauert.
- Wenn die Firmware einfach zu lange dauert, um den Befehl nach einem Timeout abzuschließen, kann die LE den WDI-Befehl abschließen. Die UE behandelt sie ordnungsgemäß.
- Wenn die Firmware hängen bleibt, wird der WDI-Befehl nicht bald abgeschlossen. Wenn die Hardware zurückgesetzt wurde, muss die LE sie bei Schritt 16 abschließen, damit sie ohne spezielle Handhabung für eine potenzielle Racebedingung sicher abgeschlossen werden kann.
Der WDI-Timer wird ausgelöst, um einen WDI-Diagnosebefehl zu generieren. Dieser WDI-Befehl ist ein Aufruf des LE-Treibers MiniportWdiAdapterHangDiagnose anstelle einer WDI-OID.
LE erfasst Zustände der Hardwaresteuerungsregister und optional den vollständigen Firmwarestatus.
- Es wird erwartet, dass der IHV-Treiber Hardwareregisterinhalte sammelt, die auf 1 KB beschränkt sind, und ihn in der Funktionsrückgabe zurückgibt. Darüber hinaus sollte die LE in der Präproduktionsumgebung auch versuchen, den Firmwarekontext in Dateien abzuspeichern, damit der IHV das Debuggen nach dem Mortem gründlich durchführen kann. Der Switch kann als Registrierungsschlüssel implementiert werden, um die Sammlung von Hardwareregistern und das Firmwareimage zu steuern.
- Die LE markiert auch den aktuellen Befehl für den Abbruch. Wenn der Befehlsabschluss die Diagnose schlägt, ist es akzeptabel, wenn die LE nichts für diesen Befehl ausführt.
- Wenn dieser Befehl aussteht, kann die UE als Folge des Zurücksetzens weitere WDI-Befehle senden. Dies sind In-Flight-Befehle oder sauber-up-Befehle. Nach dem Diagnoseaufruf sollte die LE sie verarbeiten, ohne die Firmware zu berühren.
WDI empfängt den Status des Steuerelementregisters.
WDI markiert den WDI-Befehl zum Aufhängen, sodass er später von der LE angegeben wird.
WDI gibt den NDIS-Befehl ohne WDI-Vervollständigung zurück (schließt diesen ab). Dies ist sicher, da WDI NDIS-Befehle doppelt puffert.
WDI ruft NDIS zum Zurücksetzen auf und ruft NdisWriteErrorLogEntry mit dem FehlercodeNDIS_ERROR_CODE_HARDWARE_FAILURE (0xc000138a) auf. Dies führt zu einem Ereignis, das im Systemereignisprotokoll mit dem Modulnamen LE aufgezeichnet wird. Die Fehlerereignis-ID wird automatisch als (0xc000138a | 0xffff) – 0n5002 angezeigt. Wenn die LE auch denselben Fehlercode zum Schreiben von Fehlerprotokollen verwendet, sollte das erste DWORD der Daten den High-Bit-Satz (0x80000000) enthalten, um Ereignisse einfach durch die LE zu trennen. WDI verwendet 0x00000000, um die ersten DWORD-Daten zu 0x7fffffff.
Der Aufruf wird zurückgegeben.
NDIS schließt die IRP ab.
Nach diesem Punkt ruft NDIS den Bus auf, um uns zu überraschen entfernen und neu aufzuzählen. Es ist wichtig zu beachten, dass WDI NDIS-Befehle doppelt puffert, damit es nicht warten muss, bis der WDI-Befehl zurückgegeben wird, um den NDIS-Befehl abzuschließen. Dadurch entfällt die Notwendigkeit, dass die LE Abbruchlogiken ausführen muss, die notorisch komplex sind.
Der Abschluss der NDIS-OID_SET_POWER ist erforderlich, um einen Deadlock von PnP-Vorgängen zu vermeiden. Alle PnP- und Energiezustandsänderungsereignisse werden serialisiert. Dies bedeutet, dass, wenn eine Set Power OID nicht zurückgegeben wird, kann NDIS die IRP "Energie festlegen" nicht zurückgeben. Dies bedeutet, dass die Wiederherstellung zurücksetzen mit dem Surprise-Remove IRP gesperrt wird.
Zugehörige Themen
MiniportWdiAdapterHangDiagnose