MiniportReset and connection status (NDIS test)

MiniportReset and connection status (NDIS test)

Post by Pavel A » Wed, 01 Oct 2003 21:33:46



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 reset?
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

 
 
 

MiniportReset and connection status (NDIS test)

Post by Stephan Wol » Thu, 02 Oct 2003 17:02:47


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
---


Quote:>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 reset?
>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


 
 
 

MiniportReset and connection status (NDIS test)

Post by Gary G. Littl » Fri, 03 Oct 2003 03:00:26


Look at SCSI delays. I had to account for MINUTES, not just seconds to, were
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

- Show quoted text -

Quote:> >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
reset?
> >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

 
 
 

MiniportReset and connection status (NDIS test)

Post by Mitesh Desai [MSFT » Sat, 04 Oct 2003 04:07:50


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.

Mitesh
--
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,
were
> 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
> reset?
> > >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

 
 
 

MiniportReset and connection status (NDIS test)

Post by Pavel A » Sat, 04 Oct 2003 07:08:51


Mitesh, thank you very much. Really appreciated your clear explanation.

-- Pavel



Quote:> 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.

 
 
 

MiniportReset and connection status (NDIS test)

Post by Stephan Wol » Mon, 06 Oct 2003 04:07:24


I checked our GigE source code and we actually only complete the reset
when either the link is up again or a maximum wait time has expired
(some seconds).

This driver has been logo'ed by WHQL.

Stephan
---
On Thu, 2 Oct 2003 12:07:50 -0700, "Mitesh Desai [MSFT]"


>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.

>Mitesh

 
 
 

MiniportReset and connection status (NDIS test)

Post by Larry Cawle » Mon, 06 Oct 2003 14:46:13


This is a common problem with wireless devices.  The Reset cannot be
completed until the link is re-established.  With wireless devices the
entire roaming, association sequence can take some time.  In my experience,
as long as you don't indicate reset complete until the association is
complete, the NDISTester tests pass.

Larry Cawley


> I checked our GigE source code and we actually only complete the reset
> when either the link is up again or a maximum wait time has expired
> (some seconds).

> This driver has been logo'ed by WHQL.

> Stephan
> ---
> On Thu, 2 Oct 2003 12:07:50 -0700, "Mitesh Desai [MSFT]"

> >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.

> >Mitesh