Re: Interrupts are not coming sometime in NIC miniport
- From: "Stephan Wolf [MVP]" <stewo68@xxxxxxxxxxx>
- Date: 6 Nov 2006 03:14:46 -0800
An ISR should do only what is absolutely necessary, nothing more. That
is, usually, you need to check whether the IRQ was actually from your
device. This is usually done by reading some interrupt register on the
device. Then, if your device has actually requested an interrupt, you
usually disable further interrupts from this device in the ISR. Some
devices even combine these two steps into one, i.e. reading the IRQ
source register automatically clears the interrupt enable bit (only) if
an interrupt is pending.
The DPC then does all the real work. So the ISR is mainly used as a
trigger only to initiate the DPC.
Note also, that a DPC usually runs until "no more work" is to be done.
This way, interrupts can be reduced to a minimum. However, in order to
allow other DPCs to run (such that the system can "breathe"), it is
still a good idea to leave the DPC after "some time" has elapsed even
if more work is left. In this case, another DPC needs to be scheduled
of course (to handle all the left work). Since there is unfortunately
no way to directly schedule a DPC using NDIS functions, all you can do
is actually have the NIC fire another interrupt.
Stephan
---
Uv wrote:
Hello Rahul
Is this HandleInterrupt routine your ISR or your DPC?
If it is your DPC then you are going about it the wrong way : When your
device interrupts, your interrupt handler should run long enough to
pick up (copy) all the relevant data from your device and store it in a
common buffer. It should then signal your DPC routine that some data is
ready to be processed further and re-enable the NIC interrupts.
After this the ISR should return because it has nothing else to do.
Therefore in the ISR:
1. Is this interrupt for me? If not return immediately.
2. This interrupt is for me... therefore acknowledge my device so that
it knows that I have seen the interrupt.
3. Allocate non-paged memory to store the data to be passed to the DPC.
This will usually not be "allocation". It will be "pick up a memory
block from a pre-allocated list".
4. Fill up blob with data from the NICs data buffers.
5. Add blob to a queue shared between DPC and ISR.
6. Request the OS to queue a DPC
7. Cleanup if any and return from ISR
Some "arbitrarily" long time later your DPC routine is invoked. It
wakes up, checks that queue shared between ISR and DPC and finds that
there is something to do. It must remove an item from the queue
(syncronised with the ISR) and start work on it.
It loops until the queue is empty and the returns.
This is the way you are supposed to do almost any device programming
Hope this helped.
Uv
rahuljain2462607@xxxxxxxxx wrote:
Hi,
We are making a NDIS miniport driver for NIC on Windows 2000. Sometimes
miniport driver seems to hang for some fraction of seconds and then it
starts again(Packets are countinously coming to NIC). When it again
starts running first time it shows all recieve buffers are full and
again it starts running normal. we found that for that interval for
which it seems hang interrupts are not coming.
Packets are coming on NIC on same speed so why interrupts stop coming
in between for sometime.We are disabling NIC interrupt as soon as it
calls our ISR and enable interrupt when we completly handle interrupt
in HandleInterrupt routine.
Thanks,
Rahul Jain
.
- References:
- Interrupts are not coming sometime in NIC miniport
- From: rahuljain2462607
- Re: Interrupts are not coming sometime in NIC miniport
- From: Uv
- Interrupts are not coming sometime in NIC miniport
- Prev by Date: Re: help for BDA with USB(WDF) under Vista!
- Next by Date: Re: How can I disable the TaskOffload?
- Previous by thread: Re: Interrupts are not coming sometime in NIC miniport
- Next by thread: Legacy STI driver loses connection on system restart
- Index(es):
Relevant Pages
|
