Re: NDIS IM and IRQL -- Adapter shutdown

NTDEV
1

Hi All,
Its an astonished problem with me while working on IMSAMP. After installing
it normally it working well but as soon as I disable TCP/IP bindings for
Real-Adapter, IMSAMP behaves in very strange manner. After system comes up
it shows me IP-Address 0.0.0.0/0.0.0.0. This is because Real-Adapter shuts
down itself.
Why a particular adapter is shutting down? This is not problem with many
other adapter except Intel EEProAdapter, which I read is some different kind
of NIC.
What could be solution to identify and stop such adapters to shutting down
them-selves?
Personally to get IMSAMP working with this adapter only I?ve to add code to
RaiseIRQL and LowerIRQL at many places while no other NIC was creating
problem, huhhhh… Is it so poor NIC/Driver or problem is somewhere else?
Thankx Max for your IRQL suggession. I eliminate many assertion messages
except a following non-understandable assertion message
*** Assertion failed: KeIsExecutingDpc() == FALSE
*** Source File: w:\nt\private\ntos\ke\up..\wait.c, line 1106
And this occurs at the call of UNBIND from ImSamp!CleanupAdapter().
Following is stack trace…
f902b8e4 80124793 ntoskrnl!RtlAssert+0x96
f902b91c fe498263 ntoskrnl!KeWaitForSingleObject+0x1e8
f902b978 fe455f5a TDI!TdiRegisterNetAddress+0x67
f902b93c fe43c053 tcpip!ARPUnbindAdapter+0x24
f902b978 fe455f5a tcpip!DoNDISRequest+0x5b
f902b9ac fe52c2b7 tcpip!ARPUnbindAdapter+0x24
f902ba20 fe5367e4 NDIS!ndisUnloadMiniport+0xe6
f902ba34 f8fe1a23 NDIS!NdisIMDeInitializeDeviceInstance+0x20
f902ba44 f8fe18df ImSamp!CleanupAdapter+0x65
As this is not IRQL problem :))
Please if anyone points me to solution to overcome above bunch of problems.
First of all I want to stop Intel card shutting down itself when I disable
its bindings.

Thanks for taking time to write in.

– Sumit

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih

From the documentation:

Callers of NdisIMDeInitializeDeviceInstance run at IRQL PASSIVE_LEVEL.
Max

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

2

> ----------

From: xxxxx@elitecore.com[SMTP:xxxxx@elitecore.com]
Reply To: xxxxx@lists.osr.com
Sent: Monday, December 10, 2001 9:08 AM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: NDIS IM and IRQL – Adapter shutdown

Thankx Max for your IRQL suggession. I eliminate many assertion
messages
except a following non-understandable assertion message
*** Assertion failed: KeIsExecutingDpc() == FALSE
*** Source File: w:\nt\private\ntos\ke\up..\wait.c, line 1106

Non-understandable? It seems self-descriptive. Wait.c code line 1106 expects
to NOT be called when executing DPC and some your action caused it is called
while executing DPC. Note some NDIS code is called in DPC context, receive
path for example.

It is strange because DPC is executing at DISPATCH_LEVEL and
KeWaitForSingleObject() shouldn’t be called at this level (with an
exception: zero timeout). Something went wrong; didn’t you, for example,
lowered IRQL? What is the IRQL when you called
NdisIMDeInitializeDeviceInstance?

And this occurs at the call of UNBIND from ImSamp!CleanupAdapter().
Following is stack trace…
f902b8e4 80124793 ntoskrnl!RtlAssert+0x96
f902b91c fe498263 ntoskrnl!KeWaitForSingleObject+0x1e8
f902b978 fe455f5a TDI!TdiRegisterNetAddress+0x67
f902b93c fe43c053 tcpip!ARPUnbindAdapter+0x24
f902b978 fe455f5a tcpip!DoNDISRequest+0x5b
f902b9ac fe52c2b7 tcpip!ARPUnbindAdapter+0x24
f902ba20 fe5367e4 NDIS!ndisUnloadMiniport+0xe6
f902ba34 f8fe1a23 NDIS!NdisIMDeInitializeDeviceInstance+0x20
f902ba44 f8fe18df ImSamp!CleanupAdapter+0x65
As this is not IRQL problem :))
Please if anyone points me to solution to overcome above bunch of
problems.

Bad news: to overcome such problems you need to understand how NDIS works
and what you’re doing. Sorry, I assume you don’t when saw the “solution”
with KeRaiseIrql / KeLowerIrql. Even if it is necessary, it seldom works on
SMP.

Start studying the docs. Before adding any code to ImSamp carefully read
docs for all used function and their requirements. Add assertions to your
code to test these requirements. Debug NDIS. When a problem occurs, trace
kernel code to see what occured and why it doesn’t work. When an assert
failure occurs in kernel, try to understand what failed and why kernel
developers placed this assertion there. Disassemble NDIS. If there is
something you don’t understand from docs and example, try to see NDIS code
and maybe you’ll understand better. Sure, it is necessary to read assembly
well. Always assume your bug when problem occurs. It is possible there is a
bug in kernel or another driver but compare probabilities. Seems hard? Who
said kernel development is easy? As you could see, kernel developers are
paid better than cleaning ladies in some countries :wink:

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

3

Hi,

Does PCAUSA “Sample NDIS Intermediate Driver For Windows NT 4.0 (PCASIM)”
or any other NDIS IM Driver support multiple packet receive? If no then I
got solution to all my problems. If I NULLify ReceivePacketHandler of
NDIS_PROTOCOL_CHARACTERISTICS, a very smooth operation…
I’d like someone to explain if there is any limitation or bug in NDIS
implementation for ReceivePacketHandler. If NDIS is perfect then it may be
problem with adapter driver of NIC as I’m sure its not my coding problem in
any way. And infact it is Ms coding of IMSAMP ;-).

– Sumit

-----Original Message-----
[mailto:xxxxx@lists.osr.com]On Behalf Of Michal Vodicka

From: xxxxx@elitecore.com[SMTP:xxxxx@elitecore.com]
Subject: [ntdev] Re: NDIS IM and IRQL – Adapter shutdown

Thankx Max for your IRQL suggession. I eliminate many assertion
messages
except a following non-understandable assertion message
*** Assertion failed: KeIsExecutingDpc() == FALSE
*** Source File: w:\nt\private\ntos\ke\up..\wait.c, line 1106

Non-understandable? It seems self-descriptive. Wait.c code line 1106 expects
to NOT be called when executing DPC and some your action caused it is called
while executing DPC. Note some NDIS code is called in DPC context, receive
path for example.

It is strange because DPC is executing at DISPATCH_LEVEL and
KeWaitForSingleObject() shouldn’t be called at this level (with an
exception: zero timeout). Something went wrong; didn’t you, for example,
lowered IRQL? What is the IRQL when you called
NdisIMDeInitializeDeviceInstance?

And this occurs at the call of UNBIND from ImSamp!CleanupAdapter().
Following is stack trace…
f902b8e4 80124793 ntoskrnl!RtlAssert+0x96
f902b91c fe498263 ntoskrnl!KeWaitForSingleObject+0x1e8
f902b978 fe455f5a TDI!TdiRegisterNetAddress+0x67
f902b93c fe43c053 tcpip!ARPUnbindAdapter+0x24
f902b978 fe455f5a tcpip!DoNDISRequest+0x5b
f902b9ac fe52c2b7 tcpip!ARPUnbindAdapter+0x24
f902ba20 fe5367e4 NDIS!ndisUnloadMiniport+0xe6
f902ba34 f8fe1a23 NDIS!NdisIMDeInitializeDeviceInstance+0x20
f902ba44 f8fe18df ImSamp!CleanupAdapter+0x65
As this is not IRQL problem :))
Please if anyone points me to solution to overcome above bunch of
problems.

Bad news: to overcome such problems you need to understand how NDIS works
and what you’re doing. Sorry, I assume you don’t when saw the “solution”
with KeRaiseIrql / KeLowerIrql. Even if it is necessary, it seldom works on
SMP.

Start studying the docs. Before adding any code to ImSamp carefully read
docs for all used function and their requirements. Add assertions to your
code to test these requirements. Debug NDIS. When a problem occurs, trace
kernel code to see what occured and why it doesn’t work. When an assert
failure occurs in kernel, try to understand what failed and why kernel
developers placed this assertion there. Disassemble NDIS. If there is
something you don’t understand from docs and example, try to see NDIS code
and maybe you’ll understand better. Sure, it is necessary to read assembly
well. Always assume your bug when problem occurs. It is possible there is a
bug in kernel or another driver but compare probabilities. Seems hard? Who
said kernel development is easy? As you could see, kernel developers are
paid better than cleaning ladies in some countries :wink:

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

4

Sumit,

The PCAUSA NDIS IM samples support operation using the ReceivePacketHandler
only on NDIS 5.0 and higher. We don’t use it on NDIS 4.0.

Regards,

Thomas F. Divine

PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - NDIS Intermediate - TDI Client/Filter
http: - http:

----- Original Message -----
From: “Sumit Pandya”
To: “NT Developers Interest List”
Sent: Wednesday, December 12, 2001 8:01 AM
Subject: [ntdev] Re: NDIS IM and IRQL – Adapter shutdown

> Hi,
>
> Does PCAUSA “Sample NDIS Intermediate Driver For Windows NT 4.0 (PCASIM)”
> or any other NDIS IM Driver support multiple packet receive? If no then I
> got solution to all my problems. If I NULLify ReceivePacketHandler of
> NDIS_PROTOCOL_CHARACTERISTICS, a very smooth operation…
> I’d like someone to explain if there is any limitation or bug in
NDIS
> implementation for ReceivePacketHandler. If NDIS is perfect then it may be
> problem with adapter driver of NIC as I’m sure its not my coding problem
in
> any way. And infact it is Ms coding of IMSAMP ;-).
>
> – Sumit
>
> -----Original Message-----
> [mailto:xxxxx@lists.osr.com]On Behalf Of Michal Vodicka
>
> > ----------
> > From: xxxxx@elitecore.com[SMTP:xxxxx@elitecore.com]
> > Subject: [ntdev] Re: NDIS IM and IRQL – Adapter shutdown
> >
> > Thankx Max for your IRQL suggession. I eliminate many assertion
> > messages
> > except a following non-understandable assertion message
> > Assertion failed: KeIsExecutingDpc() == FALSE
> > Source File: w:\nt\private\ntos\ke\up..\wait.c, line 1106
> >
> Non-understandable? It seems self-descriptive. Wait.c code line 1106
expects
> to NOT be called when executing DPC and some your action caused it is
called
> while executing DPC. Note some NDIS code is called in DPC context, receive
> path for example.
>
> It is strange because DPC is executing at DISPATCH_LEVEL and
> KeWaitForSingleObject() shouldn’t be called at this level (with an
> exception: zero timeout). Something went wrong; didn’t you, for example,
> lowered IRQL? What is the IRQL when you called
> NdisIMDeInitializeDeviceInstance?
>
> > And this occurs at the call of UNBIND from ImSamp!CleanupAdapter().
> > Following is stack trace…
> > f902b8e4 80124793 ntoskrnl!RtlAssert+0x96
> > f902b91c fe498263 ntoskrnl!KeWaitForSingleObject+0x1e8
> > f902b978 fe455f5a TDI!TdiRegisterNetAddress+0x67
> > f902b93c fe43c053 tcpip!ARPUnbindAdapter+0x24
> > f902b978 fe455f5a tcpip!DoNDISRequest+0x5b
> > f902b9ac fe52c2b7 tcpip!ARPUnbindAdapter+0x24
> > f902ba20 fe5367e4 NDIS!ndisUnloadMiniport+0xe6
> > f902ba34 f8fe1a23 NDIS!NdisIMDeInitializeDeviceInstance+0x20
> > f902ba44 f8fe18df ImSamp!CleanupAdapter+0x65
> > As this is not IRQL problem :))
> > Please if anyone points me to solution to overcome above bunch of
> > problems.
> >
> Bad news: to overcome such problems you need to understand how NDIS works
> and what you’re doing. Sorry, I assume you don’t when saw the “solution”
> with KeRaiseIrql / KeLowerIrql. Even if it is necessary, it seldom works
on
> SMP.
>
> Start studying the docs. Before adding any code to ImSamp carefully read
> docs for all used function and their requirements. Add assertions to your
> code to test these requirements. Debug NDIS. When a problem occurs, trace
> kernel code to see what occured and why it doesn’t work. When an assert
> failure occurs in kernel, try to understand what failed and why kernel
> developers placed this assertion there. Disassemble NDIS. If there is
> something you don’t understand from docs and example, try to see NDIS code
> and maybe you’ll understand better. Sure, it is necessary to read assembly
> well. Always assume your bug when problem occurs. It is possible there is
a
> bug in kernel or another driver but compare probabilities. Seems hard? Who
> said kernel development is easy? As you could see, kernel developers are
> paid better than cleaning ladies in some countries :wink:
>
> 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: xxxxx@pcausa.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</http:></http:>