Condividi tramite


Rilevamento blocchi UE: Passaggi da 1 a 14

I passaggi da 1 a 14 di rilevamento blocchi UE sono descritti di seguito. I passaggi corrispondono al diagramma illustrato nel flusso di rilevamento e ripristino di blocco UE.

Questo esempio usa OID_SET_POWER.

  1. NDIS riceve un'IRP di alimentazione del sistema o i riferimenti attivi della scheda di interfaccia di rete scendono a 0.

  2. NDIS genera un OID_SET_POWER D3 nel driver WDI.

  3. WDI imposta un timer per un comando WDI (M1), inclusa un'attività prima di inviare l'OID WDI verso il basso al le. Se il comando è un'attività, viene impostato anche un timer aggiuntivo per l'attività. Entrambi i timer possono eseguire il timeout, ma al massimo uno può attivare un ripristino di reimpostazione.

  4. WDI invia il comando WDI a LE. La raccomandazione per l'OID è ricordare l'OID WDI nella struttura dell'adattatore se necessita di un comando firmware per completare l'OID. Quando il firmware completa il processo per l'OID WDI, il LE completa l'OID e lo rimuove dalla struttura dell'adattatore. Poiché WDI serializza gli ID al le, il LE deve ricordare solo uno slot per ricordare l'OID WDI in sospeso. Se il comando del firmware è bloccato, l'OID può restituire l'OID in qualsiasi momento, ma non più tardi di quando il firmware è stato disabilitato (può essere nel contesto di rimozione delle sorprese) al passaggio 17. Per tutti gli altri casi, l'OID WDI completa semplicemente l'OID WDI quando il firmware completa il processo corrispondente, indipendentemente dal fatto che sia prima o dopo un callback diagnostico. Se il le deve ricordare l'OID WDI dopo la diagnosi, è necessario un altro slot per ricordarlo. Tuttavia, per gli OID ricevuti dopo la diagnosi, il leve non deve toccare il firmware per evitare blocchi a catena.

  5. Le le invia un comando al firmware.

  6. Se il timeout del comando del firmware potrebbe essere dovuto a un'interruzione del firmware o a un tempo troppo lungo.

    • Se il firmware richiede troppo tempo per completare il comando dopo un timeout, l'oggetto LE può completare il comando WDI. L'UE la gestisce in modo appropriato.
    • Se il firmware è bloccato, il comando WDI non viene completato presto. Il LE deve completarlo al passaggio 16 quando l'hardware è stato reimpostato, quindi è sicuro di completare senza una gestione speciale per una potenziale condizione di gara.
  7. Il timer WDI viene attivato per generare un comando Di diagnosi WDI. Questo comando WDI è una chiamata al driver LE, MiniportWdiAdapterHangDiagnose, anziché un OID WDI.

  8. LE raccoglie gli stati di registrazione del controllo hardware e, facoltativamente, lo stato completo del firmware.

    • Il driver IHV dovrebbe raccogliere il contenuto del registro hardware limitato a 1 KB e restituirlo nella funzione restituito. Inoltre, nell'ambiente di pre-produzione, il le deve anche provare a eseguire il dump del contesto del firmware in file in modo che l'IHV possa eseguire il debug post-mortem in modo accurato. Il commutatore può essere implementato come chiave del Registro di sistema per controllare la raccolta di registri hardware e l'immagine del firmware.
    • L'oggetto LE contrassegna anche il comando corrente per l'annullamento. Se il completamento del comando corre per battere la diagnosi, è accettabile se il le non fa nulla per questo comando.
    • Con questo comando in sospeso, l'UE può inviare altri comandi WDI come conseguenza di Reimpostazione. Questi sono comandi in anteprima o comandi di pulizia. Dopo la chiamata di diagnosi, l'ALE deve elaborarli senza toccare il firmware.
  9. WDI riceve lo stato del registro di controllo.

  10. WDI contrassegna il comando WDI di blocco in modo che sia indicato in un secondo momento da LE.

  11. WDI restituisce (completa) il comando NDIS senza il completamento di WDI. Questo è sicuro perché i comandi NDIS di WDI double-buffers sono sicuri.

  12. WDI chiama NDIS per reimpostare e chiamare NdisWriteErrorLogEntry con codice di errore di NDIS_ERROR_CODE_HARDWARE_FAILURE (0xc000138a ). Ciò comporta un evento registrato nel registro eventi di sistema con il nome del modulo di LE. L'ID evento di errore viene visualizzato automaticamente come (0xc000138a | 0xffff) – 0n5002. Se il codice di errore usa anche lo stesso codice di errore per scrivere i log degli errori, la prima DWORD dei dati deve contenere il set di bit elevato (0x80000000) per separare facilmente gli eventi da LE. WDI usa 0x00000000 per 0x7fffffff per i primi dati DWORD.

  13. La chiamata restituisce.

  14. NDIS completa l'IRP.

Dopo questo punto, NDIS chiama il bus per sorprendere rimuovere e rinumerare noi. È importante notare che i comandi NDIS wdI doppio buffer in modo che non sia necessario attendere che il comando WDI venga restituito per completare il comando NDIS. Ciò consente di eliminare la necessità di eseguire le logiche di annullamento, che sono notoriamente complesse da eseguire.

Il completamento dell'OID_SET_POWER NDIS è necessario per evitare un deadlock delle operazioni PnP. Tutti gli eventi di modifica dello stato di alimentazione e PnP vengono serializzati. Ciò significa che se un OID di alimentazione impostata non restituisce, NDIS non è in grado di restituire l'IRP di alimentazione impostata, ovvero il blocco Reimposta ripristino con l'Surprise-Remove IRP.

MiniportWdiAdapterHangDiagnose

Reimpostazione (rimozione sorpresa): passaggi da 15 a 20

Rilevamento e recupero di blocchi UE