1.7  Intermediate Driver Reset Operations

An intermediate driver must be prepared to handle the situation where its outstanding sends on a binding to an underlying driver can be aborted because the underlying NIC is reset.

An underlying driver resets its NIC, usually because NDIS calls the NIC driver’s MiniportReset function if NDIS times out queued sends or requests bound for the NIC. If an underlying NIC is reset, NDIS calls the ProtocolStatus function of each bound protocol and intermediate driver with a status of NDIS_STATUS_RESET_START, and then calls the same bound driver’s ProtocolStatusComplete function. When the NIC driver completes the reset, NDIS again calls ProtocolStatus with a status of NDIS_STATUS_RESET_END followed by a call to ProtocolStatusComplete.

When a NIC is reset, if a bound intermediate driver has any transmit packets pending to that NIC, NDIS completes those packets back to the intermediate driver with an appropriate status. The intermediate driver must resubmit these packets again when the reset is completed.

When an intermediate driver receives a status of NDIS_STATUS_RESET_START, it should:

·Hold any packets ready to be transmitted until ProtocolStatus receives an NDIS_STATUS_RESET_COMPLETE notification and ProtocolStatusComplete is called.

·Hold any received packets that are ready to be indicated up to the next higher driver until ProtocolStatus receives an NDIS_STATUS_RESET_COMPLETE notification and ProtocolStatusComplete is called.

·Clean up any internal state it maintains for in-progress operations and NIC status.

After ProtocolStatus receives an NDIS_STATUS_RESET_END message and ProtocolStatusComplete is called, the intermediate driver can resume sending packets, making requests and making indications to higher level drivers.

Because an intermediate driver usually disables timing out of sends and requests by NDIS when it calls NdisMSetAttributesEx, its MiniportReset function is seldom called. If MiniportReset is called, possibly because a higher level driver called NdisReset, the intermediate driver should reset its internal state if necessary and it should always set AddressingReset to TRUE before it returns. When the underlying NIC is reset, NDIS will send requests to MiniportSetInformation to reset the intermediate drivers internal address state for the underlying NIC if the NIC is in a condition to continue transmitting and receiving packets. MiniportReset does not have to complete outstanding sends; NDIS will fail any outstanding sends from the higher level driver appropriately. However, associated state kept by the intermediate driver possibly should be cleaned up.

An intermediate driver can initiate a reset operation by calling NdisReset. If the reset request returns NDIS_STATUS_PENDING, ProtocolResetComplete is called when the underlying NIC or virtual NIC is reset and the driver for the NIC calls NdisMResetComplete. An intermediate driver seldom calls NdisReset unless it has special knowledge that the underlying NIC is not functioning correctly. For instance, if an intermediate driver detects that it has not received completion calls for an unusually large number of sends or requests, and if it has enough knowledge of the underlying NIC to conclude there is a problem, it can call NdisReset. Usually, however, the need for a NIC reset is detected and initiated by NDIS and the NIC driver using their time-out logic.