Protocol Driver Reset Operations (NDIS 5.1)

Note   NDIS 5. x has been deprecated and is superseded by NDIS 6. x. For new NDIS driver development, see Network Drivers Starting with Windows Vista. For information about porting NDIS 5. x drivers to NDIS 6. x, see Porting NDIS 5.x Drivers to NDIS 6.0.

To initiate a reset operation, a protocol driver calls NdisReset. If its reset request returns NDIS_STATUS_PENDING, NDIS calls ProtocolResetCompletewhen the reset operation is complete.

A protocol driver seldom calls NdisResetunless it has special knowledge that the underlying NIC is not functioning correctly. For instance, if a protocol driver detects that it has not received completion calls for an unusually large number of sends or requests, and it has enough knowledge of the underlying NIC to conclude that this indicates hardware problems, it can call NdisReset. Typically, however, the need for a reset is detected and initiated by NDIS and/or the NIC's miniport driver using time-out logic. Any protocol driver bound to an underlying NDIS driver that reports its medium type as NdisMediumWan cannot call NdisReset.

Typically, an underlying miniport driver resets its NIC because the NIC is timing out during send or request operations. This condition causes NDIS to call the miniport driver's MiniportCheckForHangand subsequently MiniportResetfunctions. Alternatively, the miniport driver determines the NIC's receive capability is dysfunctional.

If a reset is initiated by NDIS and MiniportResetreturns NDIS_STATUS_PENDING, NDIS first calls the ProtocolStatus(or ProtocolCoStatus) function of each bound protocol driver with a status of NDIS_STATUS_RESET_START, and then calls the same bound protocol driver's ProtocolStatusCompletefunction. When the miniport driver calls NdisMResetComplete, NDIS again calls ProtocolStatus(or ProtocolCoStatus) with a status of NDIS_STATUS_RESET_END followed by a call to ProtocolStatusComplete.

A protocol driver must handle the possibility that outstanding sends on a binding to an underlying NIC can be canceled because the NIC is reset. If a bound protocol driver has any transmit packets pending, NDIS will indicate a send complete to the protocol driver with an appropriate status. The protocol driver must resubmit the packets when the reset operation is completed, assuming the NIC becomes operational again.

When a protocol driver receives a status of NDIS_STATUS_RESET_START, it should do the following:

  • Hold any packets ready to be transmitted until Protocol(Co)Status receives an NDIS_STATUS_RESET_END notification.

  • Not make any NDIS calls directed to the underlying miniport driver, except calls to return resources such as returning packets with NdisReturnPackets.

After ProtocolStatus(or ProtocolCoStatus) receives an NDIS_STATUS_RESET_END message and ProtocolStatusCompleteis called, the protocol driver can resume sending packets and requests.

 

 

Send comments about this topic to Microsoft