Détection de blocage d’UE : étapes 1 à 14
Les étapes 1 à 14 de la détection de blocage d’UE sont décrites ci-dessous. Les étapes correspondent au diagramme illustré dans le flux de détection et de récupération de blocage d’UE.
Cet exemple utilise OID_SET_POWER.
NDIS reçoit un IRP d’alimentation système ou les références actives de la carte réseau passent à 0.
NDIS génère un OID_SET_POWER D3 au pilote WDI.
WDI définit un minuteur pour une commande WDI (M1), y compris une tâche avant d’envoyer l’OID WDI au LE. Si la commande est une tâche, un minuteur supplémentaire pour la tâche est également défini. Les deux minuteurs peuvent expirer, mais au maximum, un seul peut déclencher une récupération de réinitialisation.
WDI envoie la commande WDI au LE. La recommandation pour le LE est de mémoriser l’OID WDI dans la structure de l’adaptateur s’il a besoin d’une commande de microprogramme pour terminer l’OID. Lorsque le microprogramme termine le travail pour l’OID WDI, le LE termine l’OID et le supprime de la structure de l’adaptateur. Étant donné que WDI sérialise les OID dans le LE, le LE n’a besoin que d’un seul emplacement pour mémoriser l’OID WDI en attente. Si la commande du microprogramme est suspendue, le LE peut retourner l’OID à tout moment, mais pas plus tard qu’à surprise-remove (cela peut être dans le contexte de surprise-remove) à l’étape 17 lorsque le microprogramme a été désactivé. Dans tous les autres cas, le LE termine simplement l’OID WDI lorsque le microprogramme termine le travail correspondant, qu’il soit avant ou après un rappel de diagnostic. Si le LE doit mémoriser l’OID WDI après le diagnostic, il a besoin d’un autre emplacement pour le mémoriser. Toutefois, pour les OID reçus après diagnostic, le LE ne doit pas toucher le microprogramme pour éviter les blocages en cascade.
Le LE envoie une commande au microprogramme.
Si la commande du microprogramme a expiré, cela peut être dû à un microprogramme qui se bloque ou prend trop de temps.
- Si le microprogramme prend simplement trop de temps pour terminer la commande après un délai d’attente, le LE peut terminer la commande WDI. L’UE le gère de manière appropriée.
- Si le microprogramme est suspendu, la commande WDI n’est pas bientôt terminée. Le LE doit l’effectuer à l’étape 16 lorsque le matériel a été réinitialisé, de sorte qu’il est sûr de se terminer sans gestion spéciale pour une condition de course potentielle.
Le minuteur WDI se déclenche pour générer une commande de diagnostic WDI. Cette commande WDI est un appel au pilote LE, MiniportWdiAdapterHangDiagnose, plutôt qu’à un OID WDI.
LE collecte les états du registre de contrôle matériel et éventuellement l’état complet du microprogramme.
- Le pilote IHV est censé collecter le contenu de l’enregistrement matériel limité à 1 Ko et le retourner dans la fonction de retour. En outre, dans l’environnement de préproduction, le LE doit également essayer de vider le contexte du microprogramme dans des fichiers afin que l’IHV puisse effectuer le débogage post-mortem minutieusement. Le commutateur peut être implémenté en tant que clé de Registre pour contrôler la collection de registres matériels et l’image du microprogramme.
- Le LE marque également l’annulation de la commande actuelle. Si l’achèvement des commandes bat le diagnostic, il est acceptable si le LE ne fait rien pour cette commande.
- Une fois cette commande en attente, l’UE peut envoyer d’autres commandes WDI en conséquence de la réinitialisation. Il s’agit de commandes en cours d’exécution ou de commandes propre-up. Après l’appel de diagnostic, le LE doit les traiter sans toucher au microprogramme.
WDI reçoit l’état du registre de contrôle.
WDI marque la commande WDI de suspension afin qu’elle soit indiquée ultérieurement par le LE.
WDI retourne (termine) la commande NDIS sans l’achèvement WDI. Ceci est sécurisé, car WDI double-buffers commandes NDIS.
WDI appelle NDIS pour réinitialiser et appelle NdisWriteErrorLogEntry avec le code d’erreur de NDIS_ERROR_CODE_HARDWARE_FAILURE (0xc000138a). Il en résulte un événement enregistré dans le journal des événements système avec le nom de module LE. L’ID d’événement d’erreur apparaît automatiquement sous la forme (0xc000138a | 0xffff) – 0n5002. Si le LE utilise également le même code d’erreur pour écrire les journaux d’erreur, le premier DWORD des données doit contenir l’ensemble de bits élevés (0x80000000) pour séparer facilement les événements par le LE. WDI utilise 0x00000000 pour 0x7fffffff pour les premières données DWORD.
L’appel est retourné.
NDIS termine l’IRP.
Après ce point, NDIS appelle le bus pour nous supprimer et nous énumérer à nouveau. Il est important de noter que WDI double-buffers commandes NDIS afin qu’il n’ait pas à attendre que la commande WDI retourne pour terminer la commande NDIS. Cela élimine la nécessité pour le LE d’effectuer des logiques d’annulation, qui sont notoirement complexes à faire.
L’achèvement du OID_SET_POWER NDIS est nécessaire pour éviter un blocage des opérations PnP. Tous les événements pnP et de changement d’état d’alimentation sont sérialisés. Cela signifie que si un set power OID ne retourne pas, NDIS n’est pas en mesure de renvoyer l’IRP d’alimentation set, ce qui signifie que la récupération de réinitialisation se verrouille avec l’IRP Surprise-Remove.
Rubriques connexes
MiniportWdiAdapterHangDiagnose