Ndis4.0 Miniport Virtual NIC driver(written for NT4.0), Serialized driver with Single Send support. The Device Operates at baud rate 19200.
Since Ndis4.0 doesn’t support WDM Lower edge i ensure that all Calls to Ndis are made from NdisContext by using Ndis Timers.
WHQL Test Kit used
WHQL NdisTest Kit Version 3.77
My Problem
The Send test in the test kit (1c_sends)waits in the middle and breaks where the debugger(softice) messages say that
“sendcomplete is not received within 10.5 sec for a set of packets.”
But from my observation, My driver, completes all send Requests to the MiniportSend routine with status success from within the MiniportSend routine itself.
Query#1: I’d like to know how the test driver arrives at this value “10.5 sec”. Is this value hard coded or calculated based on Miniport drivers response to OID_GEN_LINK_SPEED ?
Has any one observed such problem with WHQL Test kits for Ndis NIC Miniport drivers?
Thanx in advance
Regards
AN
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
When you say “My driver, completes all send Requests to the
MiniportSend routine with status success from within the MiniportSend
routine itself” - does that mean you return NDIS_STATUS_SUCCESS or you
call NdisMSendComplete() from within MiniportSend() context?
Note that the latter implies problems due to a bug in NDIS. MS never
confirmed on this but several people have seen this problem either.
If you always (!) return NDIS_STATUS_SUCCESS from your MiniportSend(),
then everything should be just fine.
Note, however, that I am not sure if timers are actually also
serialized in a miniport (I think they aren’t). This is, timer
routines might be called even if some other miniport routine is
already active. Thus, care must be taken to synchronize any data
shared between timers and other miniport routines.
HTH, Stephan
On 23 Jan 2002 14:35:28 -0000, “Anandhi” wrote:
> > >Hi Devs,=0A---------=0AMy Driver=0A---------=0ANdis4.0 Miniport Virtual NIC= > driver(written for NT4.0), Serialized driver with Single Send support. The= > Device Operates at baud rate 19200.=0ASince Ndis4.0 doesn’t support WDM Lo= >wer edge i ensure that all Calls to Ndis are made from NdisContext by using= > Ndis Timers. =0A-------------------=0AWHQL Test Kit used=0A---------------= >----=0AWHQL NdisTest Kit Version 3.77 =0A=0A------------=0AMy Problem=0A—= >---------=0AThe Send test in the test kit (1c_sends)waits in the middle and= > breaks where the debugger(softice) messages say that =0A"sendcomplete is n= >ot received within 10.5 sec for a set of packets." =0ABut from my observati= >on, My driver, completes all send Requests to the MiniportSend routine with= > status success from within the MiniportSend routine itself. =0A=0AQuery#1:= > I’d like to know how the test driver arrives at this value “10.5 sec”. Is = >this value hard coded or calculated based on Miniport drivers response to O= >ID_GEN_LINK_SPEED ? =0A=0AHas any one observed such problem with WHQL Test = >kits for Ndis NIC Miniport drivers?=0A=0AThanx in advance=0ARegards=0AAN=0A= > =0A > >— >You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’) >To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
— You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’) To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
When you say “My driver, completes all send Requests to the
MiniportSend routine with status success from within the MiniportSend
routine itself” - does that mean you return NDIS_STATUS_SUCCESS or you
call NdisMSendComplete() from within MiniportSend() context?
Note that the latter implies problems due to a bug in NDIS. MS never
confirmed on this but several people have seen this problem either.
If you always (!) return NDIS_STATUS_SUCCESS from your MiniportSend(),
then everything should be just fine.
Note, however, that I am not sure if timers are actually also
serialized in a miniport (I think they aren’t). This is, timer
routines might be called even if some other miniport routine is
already active. Thus, care must be taken to synchronize any data
shared between timers and other miniport routines.
HTH, Stephan
On 23 Jan 2002 14:35:28 -0000, “Anandhi” > wrote: > > > > > > >Hi Devs,=0A---------=0AMy Driver=0A---------=0ANdis4.0 Miniport Virtual NIC= > > driver(written for NT4.0), Serialized driver with Single Send support. The= > > Device Operates at baud rate 19200.=0ASince Ndis4.0 doesn’t support WDM Lo= > >wer edge i ensure that all Calls to Ndis are made from NdisContext by using= > > Ndis Timers. =0A-------------------=0AWHQL Test Kit used=0A---------------= > >----=0AWHQL NdisTest Kit Version 3.77 =0A=0A------------=0AMy Problem=0A—= > >---------=0AThe Send test in the test kit (1c_sends)waits in the middle and= > > breaks where the debugger(softice) messages say that =0A"sendcomplete is n= > >ot received within 10.5 sec for a set of packets." =0ABut from my observati= > >on, My driver, completes all send Requests to the MiniportSend routine with= > > status success from within the MiniportSend routine itself. =0A=0AQuery#1:= > > I’d like to know how the test driver arrives at this value “10.5 sec”. Is = > >this value hard coded or calculated based on Miniport drivers response to O= > >ID_GEN_LINK_SPEED ? =0A=0AHas any one observed such problem with WHQL Test = > >kits for Ndis NIC Miniport drivers?=0A=0AThanx in advance=0ARegards=0AAN=0A= > > =0A > > > >— > >You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’) > >To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com > > — > You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’) > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
— You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’) To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
How do you “block the MiniportSend” or, in general, how can you block
any function running at IRQL DISPATCH_LEVEL?
Since your driver is operating at 19.2 kbps, that would then be an
explanation for the long delays that the NDIS Tester is complaining
about.
If you actually need to busy loop or otherwise “block” in your send
handler, better use a work item (NdisScheduleWorkItem) for your send
handler so it can operate asynchronously at IRQL PASSIVE_LEVEL.
Stephan
On Thu, 24 Jan 2002 10:4:15, “Anandhi” wrote:
> >Hi, >I block the MiniportSend till I actually send out the data and return >appropriate Send Status. > >Regards >AN
— You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’) To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
How do you “block the MiniportSend” or, in general, how can you block
any function running at IRQL DISPATCH_LEVEL?
$$ I do the blocking based on an NdisEvent, which will get set when the
send is complete.
Since your driver is operating at 19.2 kbps, that would then be an
explanation for the long delays that the NDIS Tester is complaining
about.
$$ Hmm… I don’t think this is the reason, well i am in the process trying
to fiqure out the actual reason. From my observations so far i am sure the
problem is definitely not b’coz of low baudrate. I shall get back when i
find a definite answer :o)
If you actually need to busy loop or otherwise “block” in your send
handler, better use a work item (NdisScheduleWorkItem) for your send
handler so it can operate asynchronously at IRQL PASSIVE_LEVEL.
$$ I didn’t give this a try, but i did try using MiniportTimers to call
NdisMSendComplete, for all pended packets, but that caused a lot of
probelms. I guess it is because of Serialization issue of timers U had
mentioned earlier.’
Except for the WHQL Send test failing, the Event based blocking seems to
work fine.
Regards
Anandhi
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
As specified in the docs, NdisWaitEvent() can only be called at IRQL
PASSIVE_LEVEL, which is for sure *not* the case when you call it from
MiniportSend() (runs at IRQL DISPATCH_LEVEL).
IOW, Calling NdisWaitEvent() from MiniportSend() is illegal.
I guess your problems will go away when you fix this.
Stephan
On Fri, 25 Jan 2002 8:59:43, “Anandhi” wrote:
>On 01/24/02, “xxxxx@hotmail.com (Stephan Wolf)” wrote: >> How do you “block the MiniportSend” or, in general, how can you block >> any function running at IRQL DISPATCH_LEVEL? > >$$ I do the blocking based on an NdisEvent, which will get set when the >send is complete. > >> Since your driver is operating at 19.2 kbps, that would then be an >> explanation for the long delays that the NDIS Tester is complaining >> about. > >$$ Hmm… I don’t think this is the reason, well i am in the process trying >to fiqure out the actual reason. From my observations so far i am sure the >problem is definitely not b’coz of low baudrate. I shall get back when i >find a definite answer :o) > >> >> If you actually need to busy loop or otherwise “block” in your send >> handler, better use a work item (NdisScheduleWorkItem) for your send >> handler so it can operate asynchronously at IRQL PASSIVE_LEVEL. > >$$ I didn’t give this a try, but i did try using MiniportTimers to call >NdisMSendComplete, for all pended packets, but that caused a lot of >probelms. I guess it is because of Serialization issue of timers U had >mentioned earlier.' >Except for the WHQL Send test failing, the Event based blocking seems to >work fine. > >Regards >Anandhi > >— >You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’) >To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
— You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’) To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
As specified in the docs, NdisWaitEvent() can only be called at IRQL
PASSIVE_LEVEL, which is for sure *not* the case when you call it from
MiniportSend() (runs at IRQL DISPATCH_LEVEL).
Not necessarily. I’ve seen MiniportSend() called at passive level. It was on
SMP machine under multithreaded network stress test. Some sends were called
at DISPATCH_LEVEL from receive completion path and some at PASSIVE_LEVEL on
another CPU in context of caller thread.
Anyway, you’re right. Calling NdisWaitEvent() from MiniportSend() seems as a
bad idea.
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Hmm, the docs clearly say “By default, MiniportSend runs at IRQL
DISPATCH_LEVEL”.
However, you migth have seen MiniportSendPackets() being called at
DISPATCH_LEVEL. Here the docs say for “deserialized miniports” *only*:
“The MiniportSendPackets function of a deserialized miniport can be
called at any IRQL <= DISPATCH_LEVEL”.
And in contrast: “By default, the MiniportSendPackets function of a
serialized miniport runs at IRQL DISPATCH_LEVEL”.
Stephan
On Fri, 25 Jan 2002 19:59:56 +0100, Michal Vodicka
wrote:
> >> ---------- >> From: xxxxx@hotmail.com[SMTP:xxxxx@hotmail.com] >> Reply To: xxxxx@lists.osr.com >> Sent: Friday, January 25, 2002 7:09 PM >> To: xxxxx@lists.osr.com >> Subject: [ntdev] Re: Ndis WHQL Testing (Urgent) >> >> As specified in the docs, NdisWaitEvent() can only be called at IRQL >> PASSIVE_LEVEL, which is for sure not the case when you call it from >> MiniportSend() (runs at IRQL DISPATCH_LEVEL). >> >Not necessarily. I’ve seen MiniportSend() called at passive level. It was on >SMP machine under multithreaded network stress test. Some sends were called >at DISPATCH_LEVEL from receive completion path and some at PASSIVE_LEVEL on >another CPU in context of caller thread. > >Anyway, you’re right. Calling NdisWaitEvent() from MiniportSend() seems as a >bad idea. > >Best regards, > >Michal Vodicka >STMicroelectronics Design and Application s.r.o. >[michal.vodicka@st.com, http:://www.st.com]
— You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’) To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
When I see something different than the docs clearly say, I tend to believe
my eyes
It was several years before and I already forgot details. It was surely
MiniportSend, deserialized NDIS IM driver and NT4 SP3 or above. Anyway, it
doesn’t matter. The code written for DISPATCH_LEVEL would work well even if
called at PASSIVE_LEVEL.
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
Hmm, the docs clearly say “By default, MiniportSend runs at IRQL
DISPATCH_LEVEL”.
However, you migth have seen MiniportSendPackets() being called at
DISPATCH_LEVEL. Here the docs say for “deserialized miniports” *only*:
“The MiniportSendPackets function of a deserialized miniport can be
called at any IRQL <= DISPATCH_LEVEL”.
And in contrast: “By default, the MiniportSendPackets function of a
serialized miniport runs at IRQL DISPATCH_LEVEL”.
Stephan
On Fri, 25 Jan 2002 19:59:56 +0100, Michal Vodicka
wrote: > > > > >> ---------- > >> From: xxxxx@hotmail.com[SMTP:xxxxx@hotmail.com] > >> Reply To: xxxxx@lists.osr.com > >> Sent: Friday, January 25, 2002 7:09 PM > >> To: xxxxx@lists.osr.com > >> Subject: [ntdev] Re: Ndis WHQL Testing (Urgent) > >> > >> As specified in the docs, NdisWaitEvent() can only be called at IRQL > >> PASSIVE_LEVEL, which is for sure not the case when you call it from > >> MiniportSend() (runs at IRQL DISPATCH_LEVEL). > >> > >Not necessarily. I’ve seen MiniportSend() called at passive level. It was > on > >SMP machine under multithreaded network stress test. Some sends were > called > >at DISPATCH_LEVEL from receive completion path and some at PASSIVE_LEVEL > on > >another CPU in context of caller thread. > > > >Anyway, you’re right. Calling NdisWaitEvent() from MiniportSend() seems > as a > >bad idea. > > > >Best regards, > > > >Michal Vodicka > >STMicroelectronics Design and Application s.r.o. > >[michal.vodicka@st.com, http:://www.st.com] > > — > You are currently subscribed to ntdev as: michal.vodicka@st.com > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com >
— You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’) To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
