LE ハング検出
一部のファームウェアには、ファームウェアのハングを検出できるウォッチドッグ タイマーがあります。 一部の IHV ドライバー (LE) には、ファームウェアが前進していないかどうかを検出するロジックがあります。 UE を使用すると、LE はそのような条件を示すことができます。
その表示はアダプター ポート (例: portid=0xFFFF) で示す必要があります。 既定では、この指示によって LE がトリガーされ、完全なリセット回復プロシージャ (診断の呼び出し、デバッグ情報の収集、PLDR の要求) が実行されます。
LE またはファームウェア ウォッチドッグ タイマーがファームウェアのストールを検出すると、UE からの期待値は次のようになります。
D0 の場合、
- LE は NDIS_STATUS_WDI_INDICATION_FIRMWARE_STALLED を示します。
- 表示から戻る際に、LE はストールされた WDI コマンド (存在する場合) を返します。
- UE はリセット回復 (RR) プロシージャを開始します。
Dx の場合、これはファームウェアが検出されたストールでのみ発生します。
- ファームウェアでウェイク割り込みが発生します。
- D0 コマンドの受信時に、ファームウェアがストールした理由についてウェイク理由を示します。
- D0 WDI OID を返した後、LE は NDIS_STATUS_WDI_INDICATION_FIRMWARE_STALLED を示します。
- D0:1a、1b、1c のようにプロシージャを完了します。
Dx でのハング検出
ファームウェアは Dx で進行を停止する可能性があります。 この場合、Dx は PCIe NIC ならば D3Hot、USB および SDIO ならば D2 です。 NIC はウェイクの機能を備えており、自律的にアクセス ポイントの関連付けを維持するか、関連付けられていない場合は NLO をスキャンすることが期待されます。
NIC が Dx の場合、バスが電源オフ状態になる可能性があるため、ホストへの通信はブロックされます。 したがって、LE はストールしているファームウェアを検出できません。 ファームウェア自体はこの状態を検出し、(コードのウェイク部分がまだ生きていれば) ウェイクラインを上げ、ACPI またはバスを介して NDIS wait_wake_irp を完了して間接的にスタックを D0 に持ち込む必要があります。 このため、NDIS は D0 を NIC に設定します。
ファームウェアは、このような状態のウェイクをアサートします。 LE はファームウェア ストールのウェイク理由を示す必要があります。 ウェイク理由 WDI_WAKE_REASON_CODE_FIRMWARE_STALLED は、他のウェイクの理由を含む列挙型として定義されます。
このシナリオでリセット回復が機能するためには、ファームウェアの少なくとも 2 つの部分が引き続き機能する必要があります。
- ハング検出コード。
- ウェイク割り込みをアサートするコード。
どちらか一方が不足している場合、ホスト側はファームウェアがストールしているかどうかを認識せず、RR は発生しません。 このシナリオは、設計目標の一部ではありません。
OS モジュールによってトリガーされたリセット回復
これは、IHV のための情報です。 UE と LE で検出されたハングに加えて、他の OS コンポーネントがハングを検出したり、UE をトリガーしてリセット回復プロシージャを呼び出すことがあります。 現在、Windows 10 のユーザー モード wlansvc コンポーネントは、インターネット接続を検出し、その後しばらくの間、関連付けを解除せずに DNS サーバーにアクセスできなくなると、UE へのリセット回復を要求する場合があります。 今後、Microsoft は、リセット回復をトリガーしてエンド ユーザー エクスペリエンスを強化する追加のケースを見つける可能性があります。