Miniport ISR and HandleInterrupt

Hello All,

I’ve been trying to understand something I noticed a couple days ago. In
my NDIS miniport, the ISR gets invoked when an interrupt is asserted.
The ISR reads and recognizes the interrupt and asks NDIS to queue the
interrupt handler (DPC). At this point I’ve seen one of the following
happen.

  1. The ISR gets invoked again. In this case since I’ve disabled my
    interrupts, I simply ignore the interrupt and move on. However, how can
    this happen if there is a unlikely chance that someone else is sharing
    the same interrupt line (is there a way for me to check if this is
    infact shared by another device?)

  2. Most of the time it takes only a few microseconds before which the
    interrupt handler runs. However, sometimes it takes a relatively long
    time for it to get invoked. Since I am handling receive events, my
    receive queues get full and bad things happen because the interrupt
    handler doesn’t run for a while (with interrupts disabled).

  3. Is it possible for the Interrupt handler to get swapped by another
    “thread” in the kernel. My interrupt handler gets invoked but after
    executing a few statements it’s as if it gets swapped out?

Any suggestions on things I can do or things I need to watch for?

Thanks
Ravi

Well, I did some actual measurements. On the average the OS scheduled
and runs the DPC in about 2 - 2.5us after I return from the ISR. I start
seeing problems when the DPC runs 350us after I return from the ISR. I
can’t explain why this happens.

Ravi


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@attotech.com
Sent: Monday, August 22, 2005 8:51 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Miniport ISR and HandleInterrupt

I have seen (2) happen with SCSI Miniport & Storport drivers. Usually
the DPC runs in < 1 ms after its queued, but occasionally (once every
few seconds during heavy load), its takes 10-15 ms to happen. I could
never explain why this was occurring, although I suspect some other
driver on the system was spending a long time in its own DPC, holding up
everyone else. Unfortunately, it just seems to be one of those things
you have to live with.

Jason

xxxxx@lists.osr.com wrote on 08/22/2005 11:37:15 AM:

Hello All,
I’ve been trying to understand something I noticed a couple days ago.
In my NDIS miniport, the ISR gets invoked when an interrupt is
asserted.
The ISR reads and recognizes the interrupt and asks NDIS to queue
the interrupt handler (DPC). At this point I’ve seen one of the
following happen.

  1. The ISR gets invoked again. In this case since I’ve disabled my
    interrupts, I simply ignore the interrupt and move on. However, how
    can this happen if there is a unlikely chance that someone else is
    sharing the same interrupt line (is there a way for me to check if
    this is infact shared by another device?)
  2. Most of the time it takes only a few microseconds before which
    the interrupt handler runs. However, sometimes it takes a relatively
    long time for it to get invoked. Since I am handling receive events,
    my receive queues get full and bad things happen because the interrupt

handler doesn’t run for a while (with interrupts disabled).
3) Is it possible for the Interrupt handler to get swapped by another
“thread” in the kernel. My interrupt handler gets invoked but after
executing a few statements it’s as if it gets swapped out?
Any suggestions on things I can do or things I need to watch for?
Thanks
Ravi


Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com