Compartilhar via

Detecção de travamento da UE: etapas de 1 a 14

  • Artigo

As etapas 1 a 14 da detecção de travamento da UE são descritas abaixo. As etapas correspondem ao diagrama mostrado no fluxo de recuperação e detecção de travamento da UE.

Este exemplo usa OID_SET_POWER.

  1. O NDIS recebe um IRP de energia do sistema ou as referências ativas da NIC caem para 0.

  2. O NDIS gera um OID_SET_POWER D3 para o driver WDI.

  3. O WDI define um temporizador para um comando WDI (M1), incluindo uma tarefa antes de enviar o OID WDI para baixo para o LE. Se o comando for uma tarefa, um temporizador adicional para a tarefa também será definido. Ambos os temporizadores podem chegar ao tempo limite, mas, no máximo, apenas um pode disparar uma recuperação de redefinição.

  4. O WDI envia o comando WDI para o LE. A recomendação para o LE é lembrar o OID WDI na estrutura do adaptador se precisar de um comando de firmware para concluir o OID. Quando o firmware conclui o trabalho para o OID WDI, o LE conclui o OID e o remove da estrutura do adaptador. Como o WDI serializa os OIDs para o LE, o LE precisa apenas de um slot para se lembrar do OID WDI pendente. Se o comando de firmware estiver travado, o LE poderá retornar o OID a qualquer momento, mas não mais tarde do que em surprise-remove (pode estar no contexto de surprise-remove) na Etapa 17 quando o firmware tiver sido desabilitado. Para qualquer outro caso, o LE simplesmente conclui o OID do WDI quando o firmware conclui o trabalho correspondente, independentemente de ser antes ou depois de um retorno de chamada de diagnóstico. Se o LE precisar se lembrar do OID WDI após Diagnosticar, ele precisará de outro slot para se lembrar dele. No entanto, para os OIDs recebidos após Diagnosticar, o LE não deve tocar no firmware para evitar travamentos em cascata.

  5. O LE envia um comando para o firmware.

  6. Se o comando de firmware atingiu o tempo limite, pode ser devido a um firmware deslocado ou demorando muito.

    • Se o firmware estiver demorando muito para concluir o comando após um tempo limite, o LE poderá concluir o comando WDI. A UE lida com isso adequadamente.
    • Se o firmware estiver travado, o comando WDI não será concluído em breve. O LE deve concluí-lo na remoção surpresa na Etapa 16 quando o hardware tiver sido redefinido, portanto, é seguro concluir sem tratamento especial para uma possível condição de corrida.

  7. O temporizador WDI é acionado para gerar um comando WDI Diagnos. Esse comando WDI é uma chamada para o driver LE, MiniportWdiAdapterHangDiagnose, em vez de um OID WDI.

  8. O LE coleta os estados de registro de controle de hardware e, opcionalmente, o estado completo do firmware.

    • Espera-se que o driver IHV colete conteúdo de registro de hardware limitado a 1 KB e o retorne no retorno da função. Além disso, no ambiente de pré-produção, o LE também deve tentar despejar o contexto de firmware em arquivos para que o IHV possa fazer a depuração post mortem completamente. A opção pode ser implementada como uma chave do Registro para controlar a coleção de registros de hardware e a imagem de firmware.
    • O LE também marca o comando atual para cancelamento. Se a conclusão do comando correr para superar o diagnóstico, será aceitável se o LE não fizer nada para esse comando.
    • Com esse comando pendente, a UE pode enviar mais comandos WDI como consequência da Redefinição. Estes são comandos em andamento ou comandos limpo-up. Após a chamada de diagnóstico, o LE deve processá-los sem tocar no firmware.

  9. O WDI recebe o estado de registro de controle.

  10. O WDI marca o comando WDI hang para que ele seja indicado posteriormente pelo LE.

  11. O WDI retorna (conclui) o comando NDIS sem a conclusão do WDI. Isso é seguro porque o WDI faz buffers duplos de comandos NDIS.

  12. O WDI chama o NDIS para redefinir e chama NdisWriteErrorLogEntry com código de erro de NDIS_ERROR_CODE_HARDWARE_FAILURE (0xc000138a). Isso resulta em um evento registrado no log de eventos do sistema com o nome do módulo le. A ID do evento de erro aparece automaticamente como (0xc000138a | 0xffff) – 0n5002. Se o LE também usar o mesmo código de erro para gravar logs de erros, o primeiro DWORD dos dados deverá conter o conjunto de bits alto (0x80000000) para separar facilmente os eventos pelo LE. O WDI usa 0x00000000 para 0x7fffffff para os primeiros dados DWORD.

  13. A chamada retorna.

  14. O NDIS conclui o IRP.

Após esse ponto, o NDIS chama o ônibus para nos remover e enumerar novamente. É importante observar que o WDI faz buffers duplos de comandos NDIS para que ele não precise aguardar que o comando WDI retorne para concluir o comando NDIS. Isso elimina a necessidade de o LE fazer o cancelamento de lógicas, que são notoriamente complexas de fazer.

A conclusão do NDIS OID_SET_POWER é necessária para evitar um deadlock de operações PnP. Todos os eventos de alteração de estado de energia e PnP são serializados. Isso significa que, se um OID de energia set não retornar, o NDIS não poderá retornar o IRP de energia definido, o que significa que a Recuperação de Redefinição é bloqueada com o IRP Surprise-Remove.

MiniportWdiAdapterHangDiagnose

Redefinir (remoção surpresa): etapas de 15 a 20

Detecção de travamento da UE e fluxo de recuperação