Detección de bloqueos de UE: pasos del 1 al 14
A continuación se describen los pasos del 1 al 14 de la detección de bloqueos de UE. Los pasos corresponden al diagrama que se muestra en flujo de recuperación y detección de bloqueos de UE.
En este ejemplo se usa OID_SET_POWER.
NDIS recibe un IRP de alimentación del sistema o las referencias activas de NIC bajan a 0.
NDIS genera un OID_SET_POWER D3 al controlador WDI.
WDI establece un temporizador para un comando WDI (M1), incluida una tarea antes de enviar el OID WDI a la le. Si el comando es una tarea, también se establece un temporizador adicional para la tarea. Ambos temporizadores pueden agotar el tiempo de espera, pero como máximo, solo uno puede desencadenar una recuperación de restablecimiento.
WDI envía el comando WDI al LE. La recomendación para la LE es recordar el OID WDI en la estructura del adaptador si necesita un comando de firmware para completar el OID. Cuando el firmware completa el trabajo del OID WDI, le completa el OID y lo quita de la estructura del adaptador. Dado que WDI serializa los OID a la LE, el LE solo necesita una ranura para recordar el OID WDI pendiente. Si el comando de firmware está bloqueado, el LE puede devolver el OID en cualquier momento, pero no más tarde que en la eliminación sorpresa (puede estar en el contexto de la eliminación sorpresa) en el paso 17 cuando el firmware se ha deshabilitado. Para cualquier otro caso, el LE simplemente completa el OID WDI cuando el firmware completa el trabajo correspondiente, independientemente de si es antes o después de una devolución de llamada de diagnóstico. Si el LE necesita recordar el OID WDI después de Diagnosticar, necesita otra ranura para recordarlo. Sin embargo, para los OID recibidos después de Diagnosticar, el LE no debe tocar el firmware para evitar bloqueos en cascada.
El LE envía un comando al firmware.
Si se agota el tiempo de espera del comando de firmware, puede deberse a un firmware colgado o a tardar demasiado tiempo.
- Si el firmware simplemente tarda demasiado tiempo en completar el comando después de un tiempo de espera, le puede completar el comando WDI. La UE la controla correctamente.
- Si el firmware está bloqueado, el comando WDI no se completará pronto. El LE debe completarlo en la eliminación sorpresa en el paso 16 cuando se ha restablecido el hardware, por lo que es seguro completarse sin control especial para una posible condición de carrera.
El temporizador WDI se activa para generar un comando WDI Diagnose. Este comando WDI es una llamada al controlador LE, MiniportWdiAdapterHangDiagnose, en lugar de un OID WDI.
LE recopila estados de registro de control de hardware y, opcionalmente, el estado de firmware completo.
- Se espera que el controlador IHV recopile el contenido del registro de hardware, que está limitado a 1 KB, y que lo devuelva en la devolución de la función. Además, en el entorno de preproducción, el LE también debe intentar volcar el contexto de firmware en archivos para que el IHV pueda realizar la depuración post-mortem exhaustivamente. El modificador se puede implementar como una clave del Registro para controlar la colección de registros de hardware y la imagen de firmware.
- El LE también marca el comando actual para la cancelación. Si la finalización de comandos corre para superar el diagnóstico, es aceptable si el LE no hace nada para este comando.
- Con este comando pendiente, la UE puede enviar más comandos WDI como consecuencia del restablecimiento. Se trata de comandos en curso o comandos de limpieza. Después de la llamada de diagnóstico, el LE debe procesarlos sin tocar el firmware.
WDI recibe el estado de registro del control.
WDI marca el comando WDI de bloqueo para que el LE lo indique más adelante.
WDI devuelve (completa) el comando NDIS sin la finalización de WDI. Esto es seguro porque los comandos NDIS de doble búfer WDI.
WDI llama a NDIS para restablecer y llama a NdisWriteErrorLogEntry con código de error de NDIS_ERROR_CODE_HARDWARE_FAILURE (0xc000138a). Esto da como resultado un evento registrado en el registro de eventos del sistema con el nombre del módulo de LE. El identificador de evento de error aparece automáticamente como (0xc000138a | 0xffff) – 0n5002. Si el LE también usa el mismo código de error para escribir registros de errores, el primer DWORD de los datos debe contener el conjunto de bits alto (0x80000000) para separar fácilmente los eventos por parte de LE. WDI usa 0x00000000 para 0x7fffffff para los primeros datos DWORD.
La llamada devuelve.
NDIS completa el IRP.
Después de este punto, NDIS llama al bus para sorprendernos y volver a enumerarnos. Es importante tener en cuenta que los comandos NDIS de doble búfer WDI no tienen que esperar a que el comando WDI vuelva para completar el comando NDIS. Esto elimina la necesidad de que el LE realice lógicas de cancelación, que son notoriamente complejas de hacer.
La finalización del OID_SET_POWER NDIS es necesaria para evitar un interbloqueo de operaciones PnP. Todos los eventos de cambio de estado de alimentación y PnP se serializan. Esto significa que si un OID set power no devuelve, NDIS no puede devolver el IRP set power IRP, lo que significa que reset Recovery se bloquea con el IRP de Surprise-Remove.
Temas relacionados
MiniportWdiAdapterHangDiagnose