NDIS calls DPR without ISR during init
Stephan Wolf
In my NDIS4 Miniport, MiniportHandleInterrupt() is called by the NDIS
Wrapper during execution of MiniportInitialize() without a preceding
call to MiniportISR().
What I see in the stack trace is that MiniportHandleInterrupt() is
called by ndisMDpcTimer().
My Miniport does not have the optional MiniportDisableInterrupt() and
MiniportEnableInterrupt() functions.
Has anyone ever seen this before?
The reason I am asking is that this violates the rules of NDIS
interrupt handling as described in DDK Help: "When
MiniportHandleInterrupt is called, interrupts are disabled on the NIC,
either by the MiniportISR or MiniportDisableInterrupt function".
Maybe it's just because I don't have a MiniportDisableInterrupt(),
which is optional?
Stephan Wolf <sw...@syskonnect.de> http://www.syskonnect.de
SysKonnect - The Server Connectivity Company
Dave Davis
Stephan Wolf <sw...@syskonnect.de> wrote in article
<34575def.22208263@spock>...
> In my NDIS4 Miniport, MiniportHandleInterrupt() is called by the NDIS
> Wrapper during execution of MiniportInitialize() without a preceding
> call to MiniportISR().
>
> What I see in the stack trace is that MiniportHandleInterrupt() is
> called by ndisMDpcTimer().
>
> My Miniport does not have the optional MiniportDisableInterrupt() and
> MiniportEnableInterrupt() functions.
>
> Has anyone ever seen this before?
Yes. I usually get three in a row.
I also do not have the optional MiniportDisableInterrupt() and
MiniportEnableInterrupt() functions. I just check my adapter
copy of the interrupt status register, if it is zero I return.
Russell Johnson
Stephan Wolf wrote:
> Sure, I can easily work around this, but how can one ever write a
> properly working driver when the behavior of the system is not as
> documented? This time I (accidentally) found out that something
> doesn't work as expected. But for how many other things does this also
> hold true?
>
> Now the question is: Is this a bug in the NDIS Wrapper or is it a
> documentation error or are we missing something? Kyle?
I found that if you implement the disable/enable interrupt routines, the
NDIS wrapper will call them during the time you are speaking about. If
I remember correctly, NDIS will call disable, DPC, enable before/after
each call to the OID handler during initialization. Like Dave, I ended
up removing my disable/enable routine and having my DPC just ignore the
request because there was nothing else to do.
So my interpretation is that this is not a bug because NDIS will call
your disable/enable routines if you have them. You have just taken an
optional route through your code which means you will handle the
disable/enable on your own because you didn't provide the disable/enable
routine for NDIS to call.
Hope this helps.
Russ
Stephan Wolf
On 29 Oct 1997 20:57:44 GMT, "Dave Davis"
<dave....@nospam.gsnetworks.gensig.com> wrote:
>> In my NDIS4 Miniport, MiniportHandleInterrupt() is called by the NDIS
>> Wrapper during execution of MiniportInitialize() without a preceding
>> call to MiniportISR().
...
>> Has anyone ever seen this before?
>
>Yes. I usually get three in a row.
>I also do not have the optional MiniportDisableInterrupt() and
>MiniportEnableInterrupt() functions. I just check my adapter
>copy of the interrupt status register, if it is zero I return.
Ok, so then I assume it's not a bug in my driver. Sure I can also
check if my card did really request an interrupt (calling the DPR
without a real IRQ is not a problem for my DPR, anyway).
The problem is that my DPR assumes that the card's IRQs are disabled
when it gets called, which is what the DDK Help states about (NDIS)
interrupt handling. Normally, my ISR would disable the card's IRQs.
But now the DPR gets called with IRQs enabled and then the ISR might
also get called if the card should really request an interrupt. And
this *is* a problem, since both the ISR and the DPR will modify the
card's IRQ register, which will lead to serious problems.
Sure, I can easily work around this, but how can one ever write a
properly working driver when the behavior of the system is not as
documented? This time I (accidentally) found out that something
doesn't work as expected. But for how many other things does this also
hold true?
Now the question is: Is this a bug in the NDIS Wrapper or is it a
documentation error or are we missing something? Kyle?
Stephan Wolf <sw...@syskonnect.de> http://www.syskonnect.de
Stephan Wolf
>I found that if you implement the disable/enable interrupt routines, the
>NDIS wrapper will call them during the time you are speaking about. If
>I remember correctly, NDIS will call disable, DPC, enable before/after
>each call to the OID handler during initialization. Like Dave, I ended
>up removing my disable/enable routine and having my DPC just ignore the
>request because there was nothing else to do.
Will do it this way then also.
>So my interpretation is that this is not a bug because NDIS will call
>your disable/enable routines if you have them. You have just taken an
>optional route through your code which means you will handle the
>disable/enable on your own because you didn't provide the disable/enable
>routine for NDIS to call.
I agree that this is not a real bug in NDIS. But on the other hand,
this behavior is not (yet) documented (this one goes to Kyle).
>Hope this helps.
Yes, it does. Thanks. Thanks also to Todd Thomson (I hope you don't
mind if I post your email here):
On 30 Oct 97 at 6:16, Todd J. Thomson wrote:
> I also do not have MiniportDisableInterrupt() and MiniportEnableInterrupt()
> routines in my driver. However, I have never seen the
> MiniportHandleInterrupt() routine called without the preceding call to my
> MiniportISR().
>
> During the MiniportportInitialize(), I connect the interrupt, download a
> comms kernel to my controller and then start it (it is an intelligent
> board). At that time I start to get interrupts from the controller. These
> interrupts are ALWAYS presented to the MiniportISR() where it decides if it
> wishes the NDIS wrapper to queue a DPC to handle the interrupt ( the
> MiniportHandleInterrupt() ).
On 30 Oct 97 at 15:18, Stephan Wolf wrote:
> What kind of bus does your device have (ISA/EISA/MCA/PCI)? Does it
> allow to share interrupts?
On 30 Oct 97 at 7:19, Todd J. Thomson wrote:
> My NDISWAN driver supports both ISA and PCI bus types. The PCI interrupt IS
> shareable, but I do NOT allow the selected interrupt to be shared! I have
> read that it is NOT adviseable to share interrupts. However, I cannot recall
> where I read this so please do not take this as gospel.
kyleb
below
--
The opinions expressed in this message are my own personal views
and do not reflect the official views of Microsoft Corporation
please respond to newsgroup. Do not send mail.
Stephan Wolf wrote in article <34575def.22208263@spock>...
>In my NDIS4 Miniport, MiniportHandleInterrupt() is called by the NDIS
>Wrapper during execution of MiniportInitialize() without a preceding
>call to MiniportISR().
the MiniportHandleInterrupt is called before you return from
MiniportInitialize or
before you get back from the call to NdisMRegisterMiniport?
>
>What I see in the stack trace is that MiniportHandleInterrupt() is
>called by ndisMDpcTimer().
>
>My Miniport does not have the optional MiniportDisableInterrupt() and
>MiniportEnableInterrupt() functions.
When you call NdisMRegisterInterrupt do set RequestIsr or SharedInterrupt to
TRUE?
if so then your Enable/Disable won't be called (more on that below).
Once you return from MiniportInitialize you will get a series of requests
from the wrapper.
these requests will be sent before your call to NdisMRegisterMiniport
returns on <= NT4.0 (NT 5.0 will be very different).
After each of these requests we queue a DPC to fire. This is to pickup any
stray events that the miniport may have.
Some expect some status to be set by their interrupt handler. The fact that
the ndisMDpcTimer was the caller means
this could be the result of these requests.
>
>Has anyone ever seen this before?
>
>The reason I am asking is that this violates the rules of NDIS
>interrupt handling as described in DDK Help: "When
>MiniportHandleInterrupt is called, interrupts are disabled on the NIC,
>either by the MiniportISR or MiniportDisableInterrupt function".
>
>Maybe it's just because I don't have a MiniportDisableInterrupt(),
>which is optional?
if you request that you want your isr called when you register it or if you
say that your interrupt is shared.
the you do NOT need the MiniportDisableInterrupt and
MiniportEnableInterrupt. This is because you are
expected to disable int's in your isr and enable them in your dpc.
if you don't specifically say that you want an isr then ndis will skip the
call. when the isr is triggered ndis will call
the MiniportDisableInterrupt routine and queue the dpc for you. after you
process the dpc it will call MiniportEnableInterrupt
Stephan Wolf
On Fri, 31 Oct 1997 08:40:57 -0800, "kyleb" <kyl...@microsoft.com>
wrote:
>Stephan Wolf wrote in article <34575def.22208263@spock>...
>
>>In my NDIS4 Miniport, MiniportHandleInterrupt() is called by the NDIS
>>Wrapper during execution of MiniportInitialize() without a preceding
>>call to MiniportISR().
>
>the MiniportHandleInterrupt is called before you return from
>MiniportInitialize or
>before you get back from the call to NdisMRegisterMiniport?
After MiniportInitialize() has returned, but before
NdisMRegisterMiniport() returns. I actually see several calls to
MiniportQueryInformation(), each of them immediately followed by a
call to MiniportHandleInterrupt().
>When you call NdisMRegisterInterrupt do set RequestIsr or SharedInterrupt to
>TRUE?
'RequestIsr' is always TRUE. 'SharedInterrupt' depends on EISA
configuration of our card (latched vs. level triggered IRQ). [PCI card
has 'SharedInterrupt' always set to TRUE, but I didn't check if
MiniportHandleInterrupt() also gets called there without a preceding
MiniportISR().]
>if so then your Enable/Disable won't be called (more on that below).
Yes, this was already my understanding of things.
>Once you return from MiniportInitialize you will get a series of requests
>from the wrapper.
>these requests will be sent before your call to NdisMRegisterMiniport
>returns on <= NT4.0 (NT 5.0 will be very different).
>After each of these requests we queue a DPC to fire. This is to pickup any
>stray events that the miniport may have.
>Some expect some status to be set by their interrupt handler. The fact that
>the ndisMDpcTimer was the caller means
>this could be the result of these requests.
Ok, then this is the explanation for what I see.
[If "some" really expect some status from their interrupt handler, why
don't they have a real IRQ then? How can you ever expect any
information from your interrupt handler, if there's no IRQ? Sounds
like a MS workaround for badly written 3rd-party Miniports.]
>>The reason I am asking is that this violates the rules of NDIS
>>interrupt handling as described in DDK Help: "When
>>MiniportHandleInterrupt is called, interrupts are disabled on the NIC,
>>either by the MiniportISR or MiniportDisableInterrupt function".
>>
>>Maybe it's just because I don't have a MiniportDisableInterrupt(),
>>which is optional?
>
>if you request that you want your isr called when you register it or if you
>say that your interrupt is shared.
>the you do NOT need the MiniportDisableInterrupt and
>MiniportEnableInterrupt. This is because you are
>expected to disable int's in your isr and enable them in your dpc.
>if you don't specifically say that you want an isr then ndis will skip the
>call. when the isr is triggered ndis will call
>the MiniportDisableInterrupt routine and queue the dpc for you. after you
>process the dpc it will call MiniportEnableInterrupt
Exactly. But still, the docs clearly say that there must be at least
one call to MiniportISR() before MiniportHandleInterrupt() gets
scheduled and called. This is exactly how I would expect interrupt
handling to be implemented. But now, NDIS calls
MiniportHandleInterrupt() without any IRQ (i.e. MiniportISR()) and
this is not what I expect, and it is also not documented this way.
I understand that you decided to call MiniportHandleInterrupt() after
each call to MiniportQueryInformation() during initialization, as you
explained above. But please, add some words about this to the docs.