MiniportCheckForHangEx vs MiniportCHeckForHang

Hi,
I am writing an NDIS6 miniport driver.

In WDK it is written on MiniportCheckForHangEx do that
"If a miniport driver does not complete an OID request within two
successive calls to MiniportCheckForHangEx, NDIS can call the driver's
MiniportResetEx function."

and on MiniportCheckForHang doc that:

"If a NIC driver has no MiniportCheckForHang function and NDIS judges
the driver unresponsive as, for example, when NDIS holds many pending
sends and requests queued to the miniport driver for a time-out
interval, NDIS calls the driver's MiniportReset function"

1. If I correctly understand the doc than MiniportCheckForHangEx in
contrary to MiniportCheckForHang does not care about pending sends
request only pending OIDS. I tested it by pending send requests
forever and indeed
MiniportReset was not called. Is that the expected behaviour or did I
miss something?

2. What is the meaning of "NDIS can call the driver's
MiniportResetEx?" are there times that it will not call it ?

Thanks
Miki

Alireza
Thu Apr 19 03:19:34 CDT 2007

> 1. If I correctly understand the doc than MiniportCheckForHangEx in
> contrary to MiniportCheckForHang does not care about pending sends
> request only pending OIDS. I tested it by pending send requests
> forever and indeed
> MiniportReset was not called. Is that the expected behaviour or did I
> miss something?

The documentation for the MiniportCheckForHang was written when all we had
was serialized drivers and that's where NDIS resets the adapter if it does
not complete send requests in a timely manner.
NDIS does -not- reset deserialized drivers (no matter what version) if they
pend a send request too long; so in that regard the MiniportCheckForHagEx
works the same way as MiniportCheckForHang for deserialized drivers.

> 2. What is the meaning of "NDIS can call the driver's
> MiniportResetEx?" are there times that it will not call it ?

As of now we do reset the adapter if it pends a request for too long. Going
forward there may be cases where we would not. If a miniport really wants a
reset, then it can tell NDIS that it needs a reset when we call its check
for hang handler.

-thanks, ali
--
This posting is provided "AS IS" with no warranties, and confers no rights.


"miki" <michael.waksman@gmail.com> wrote in message
news:1176967850.837854.255970@d57g2000hsg.googlegroups.com...
> Hi,
> I am writing an NDIS6 miniport driver.
>
> In WDK it is written on MiniportCheckForHangEx do that
> "If a miniport driver does not complete an OID request within two
> successive calls to MiniportCheckForHangEx, NDIS can call the driver's
> MiniportResetEx function."
>
> and on MiniportCheckForHang doc that:
>
> "If a NIC driver has no MiniportCheckForHang function and NDIS judges
> the driver unresponsive as, for example, when NDIS holds many pending
> sends and requests queued to the miniport driver for a time-out
> interval, NDIS calls the driver's MiniportReset function"
>
> 1. If I correctly understand the doc than MiniportCheckForHangEx in
> contrary to MiniportCheckForHang does not care about pending sends
> request only pending OIDS. I tested it by pending send requests
> forever and indeed
> MiniportReset was not called. Is that the expected behaviour or did I
> miss something?
>
> 2. What is the meaning of "NDIS can call the driver's
> MiniportResetEx?" are there times that it will not call it ?
>
> Thanks
> Miki
>