The NDISTest's NdisReset command initiates a MiniportReset and waits for
reset to complete before returning control to the test. The miniport would
not complete the reset until it knows its link status for certain and hence
the test should not have any problems.
The miniport can pend the reset until it can determine the link status. NDIS
and protocols know that the device is in reset and must be able to handle
long reset durations.
This posting is provided "AS IS" with no warranties, and confers no rights.
> Look at SCSI delays. I had to account for MINUTES, not just seconds to,
> a SCSI device power on at roughly the same time.
> Gary G. Little
> Seagate Technologies, LLC
> > Good question. IIRC, we had a loooong discussion with WHQL years ago
> > on this "link up after reset" issue. Our problem was that an FDDI
> > station can -by specification- require up to IIRC 50 seconds (!) to
> > "insert" into the ring.
> > I currently don't remember how we or them solved the problem.
> > Maybe it is interesting to note that auto-negotiation on Ethernet can
> > take up to 3 seconds. So I am wondering how one can ever fulfill any
> > 500 ms requirement...?
> > Stephan
> > ---
> > >The MiniportReset test checks that connection state is restored after
> reset, and gives the driver
> > >500 ms to restore connection ( script : 1c_reset.wsf, line 195 in
> ndistest 4.3.30).
> > >What if this is not enough?
> > >For wireless LAN, the same test suite allows up to 2 sec to connect
> > >(script : 1c_wlan_associatetime.wsf ).
> > >Does NDIS or any protocol actually expect the link up in 0.5 sec after
> > >Since MiniportReset does hardware reset, you can not expect reset time
> shorter than normal
> > >connection (that is typically ~ 1 sec).
> > >How do you cope with this issue? just skip hardware reset?
> > >Any advice will be greatly appreciated. Thanks in advance.
> > >-- Pavel