Problem of ISR and DPC in NDIS framework

NTDEV
1

Hi,

In my driver code for Miniport, I am receiving the Interrupt from hardware.
In Interrupt Service routine I am just setting the flag for queuing the DPC
(HandleInterruptHandler) routine.

But scenario is like this

Driver

  1. Calls function f1 to send packet to card (called at DISPATCH_LEVEL).

  2. Function f1 waits for Interrupt from hardware and
    “HandleInterruptHandler” to complete processing.

  3. Interrupt comes and sets the Flag TRUE for scheduling DPC
    “HandleInterruptHandler”(To run at Dispatch Level).

  4. Calling Function Endlessly waits for DPC “HandleInterruptHandler” to
    complete the processing, but DPC is not scheduled until calling function
    exits (I have set the timer for calling function to exit).

Problem is DPC (which is called at DISPATCH_LEVEL) is not scheduled, cause
some routine is already executing at Dispatch Level in driver.

Is my understanding is clear?
Can we some how execute the DPC even before the calling routine exits?

Regards
Chirag

2

On Fri, 2004-07-02 at 03:30, Chirag Sanghani wrote:

Driver

  1. Calls function f1 to send packet to card (called at DISPATCH_LEVEL).

Do you mean f1() is your MiniportSendPackets (or equivalent)? It
doesn’t have to be called at DISPATCH_LEVEL if that’s that’s the case,
for what that’s worth.

  1. Function f1 waits for Interrupt from hardware and
    “HandleInterruptHandler” to complete processing.

How does it wait? It’s illegal to wait at IRQL > APC_LEVEL, so I’m a
bit confused. Or do you mean that you create a new thread to wait from?

  1. Interrupt comes and sets the Flag TRUE for scheduling DPC
    “HandleInterruptHandler”(To run at Dispatch Level).

  2. Calling Function Endlessly waits for DPC “HandleInterruptHandler” to
    complete the processing, but DPC is not scheduled until calling function
    exits (I have set the timer for calling function to exit).

Are you just waiting for send confirmation or something? Is there a way
you can break this up and handle it more asynchronously? I think there
may be a cleaner design, if I understand this correctly.

Problem is DPC (which is called at DISPATCH_LEVEL) is not scheduled, cause
some routine is already executing at Dispatch Level in driver.

Is my understanding is clear?
Can we some how execute the DPC even before the calling routine exits?

You can, of course, directly call your HandleInterruptHandler(), but I’m
not sure why you would want to. Again, I’m unclear on the architecture
of your driver. Could you provide some more detail?

-sd

3

I think two processes at Same IRQL cannot be executed

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Chirag Sanghani
Sent: Friday, July 02, 2004 2:01 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Problem of ISR and DPC in NDIS framework

Hi,

In my driver code for Miniport, I am receiving the Interrupt from hardware.
In Interrupt Service routine I am just setting the flag for queuing the DPC
(HandleInterruptHandler) routine.

But scenario is like this

Driver

  1. Calls function f1 to send packet to card (called at DISPATCH_LEVEL).

  2. Function f1 waits for Interrupt from hardware and
    “HandleInterruptHandler” to complete processing.

  3. Interrupt comes and sets the Flag TRUE for scheduling DPC
    “HandleInterruptHandler”(To run at Dispatch Level).

  4. Calling Function Endlessly waits for DPC “HandleInterruptHandler” to
    complete the processing, but DPC is not scheduled until calling function
    exits (I have set the timer for calling function to exit).

Problem is DPC (which is called at DISPATCH_LEVEL) is not scheduled, cause
some routine is already executing at Dispatch Level in driver.

Is my understanding is clear?
Can we some how execute the DPC even before the calling routine exits?

Regards
Chirag

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

You are currently subscribed to ntdev as: xxxxx@patni.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Hi Steve

Again, I’m unclear on the architecture
of your driver. Could you provide some more detail?

Here are the details
I am writing a NDIS 4.0 compliant Miniport Driver for an ISDN Adapter.

The Ndis framework calls the QueryInformation function of my driver with
OID_TAPI_MAKE_CALL at the DISPATCH_LEVEL.

In response this OID , my driver calls a function f1() which sends a connect
packet to the adapter and waits for a response from the adapter. this wait
is done by a NdisWaitEvent() function with a timeout of 1 second repeatedly
for 30 times. since the QueryInformation is called at DISPATCH_LEVEL the
wait executes at DISPATCH_LEVEL.

During this wait, I receive an Interrupt from the adapter as required. In
the ISR, I indicate the Ndis Framework that I have recognized the interrupt
and schedule my HandleInterruptHandler as registered in
MINIPORT_WAN_CHARACHTERISTICS by setting the variable
“QueueMiniportHandleInterrupt = TRUE”.

This HandleInterruptHandler will perform the processing required to service
the interrupt.

However the NDIS framework is not able to schedule the
HandleInterruptHandler unless the f1() function exists its execution and
comes out of the wait.

As a result of this we always are left with no response from the adapter as
required within the wait period of 30 seconds.

Is there a way
you can break this up and handle it more asynchronously? I think there
may be a cleaner design, if I understand this correctly.

I am porting an existing Non-NDIS WinNT 4.0 device driver to NDIS 4.0
compliant driver. The existing architecture of the Non-NDIS WinNT 4.0 device
driver itself requires the connect() function to be synchronously executed
as otherwise it may create conflicts in multiple call establishment.

Further, My interrupt vector is non-sharable, In this case even if I
indicate the NDIS to directly call my HandleInterruptHandler instead of ISR
on receiving interrupt from the adapter does not help (not able to schedule
the HandleInterruptHandler during the wait period).

I am not able to make out --What could be the possible reason for such
behavior from NDIS.
Could you please help me out of this ?

Regards,
Chirag Sanghani.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Steve Dispensa
Sent: Friday, July 02, 2004 11:53 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Problem of ISR and DPC in NDIS framework

On Fri, 2004-07-02 at 03:30, Chirag Sanghani wrote:

Driver

  1. Calls function f1 to send packet to card (called at DISPATCH_LEVEL).

Do you mean f1() is your MiniportSendPackets (or equivalent)? It
doesn’t have to be called at DISPATCH_LEVEL if that’s that’s the case,
for what that’s worth.

  1. Function f1 waits for Interrupt from hardware and
    “HandleInterruptHandler” to complete processing.

How does it wait? It’s illegal to wait at IRQL > APC_LEVEL, so I’m a
bit confused. Or do you mean that you create a new thread to wait from?

  1. Interrupt comes and sets the Flag TRUE for scheduling DPC
    “HandleInterruptHandler”(To run at Dispatch Level).

  2. Calling Function Endlessly waits for DPC “HandleInterruptHandler” to
    complete the processing, but DPC is not scheduled until calling function
    exits (I have set the timer for calling function to exit).

Are you just waiting for send confirmation or something? Is there a way
you can break this up and handle it more asynchronously? I think there
may be a cleaner design, if I understand this correctly.

Problem is DPC (which is called at DISPATCH_LEVEL) is not scheduled, cause
some routine is already executing at Dispatch Level in driver.

Is my understanding is clear?
Can we some how execute the DPC even before the calling routine exits?

You can, of course, directly call your HandleInterruptHandler(), but I’m
not sure why you would want to. Again, I’m unclear on the architecture
of your driver. Could you provide some more detail?

-sd

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

You are currently subscribed to ntdev as: xxxxx@patni.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

  1. NdisWaitEvent ends up calling KeWaitForSingleObject, which can only
    be called at DISPATCH_LEVEL if the timeout is zero, which yours is not.
    Otherwise it will cause a bugcheck.

  2. Why don’t you just return PENDING to the OID query and then when you
    finally have a result, complete it via NdisMQueryInformationComplete.

  3. You may also want to look at the discussion at
    http://www.microsoft.com/whdc/device/network/LANWAN/CoNDIS-WAN.mspx.

Bryan S. Burgin
xxxxx@microsoft.com

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chirag Sanghani
Sent: Friday, July 02, 2004 10:32 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Problem of ISR and DPC in NDIS framework

Hi Steve

Again, I’m unclear on the architecture
of your driver. Could you provide some more detail?

Here are the details
I am writing a NDIS 4.0 compliant Miniport Driver for an ISDN Adapter.

The Ndis framework calls the QueryInformation function of my driver with
OID_TAPI_MAKE_CALL at the DISPATCH_LEVEL.

In response this OID , my driver calls a function f1() which sends a
connect
packet to the adapter and waits for a response from the adapter. this
wait
is done by a NdisWaitEvent() function with a timeout of 1 second
repeatedly
for 30 times. since the QueryInformation is called at DISPATCH_LEVEL the
wait executes at DISPATCH_LEVEL.

During this wait, I receive an Interrupt from the adapter as required.
In
the ISR, I indicate the Ndis Framework that I have recognized the
interrupt
and schedule my HandleInterruptHandler as registered in
MINIPORT_WAN_CHARACHTERISTICS by setting the variable
“QueueMiniportHandleInterrupt = TRUE”.

This HandleInterruptHandler will perform the processing required to
service
the interrupt.

However the NDIS framework is not able to schedule the
HandleInterruptHandler unless the f1() function exists its execution and
comes out of the wait.

As a result of this we always are left with no response from the adapter
as
required within the wait period of 30 seconds.

Is there a way
you can break this up and handle it more asynchronously? I think there
may be a cleaner design, if I understand this correctly.

I am porting an existing Non-NDIS WinNT 4.0 device driver to NDIS 4.0
compliant driver. The existing architecture of the Non-NDIS WinNT 4.0
device
driver itself requires the connect() function to be synchronously
executed
as otherwise it may create conflicts in multiple call establishment.

Further, My interrupt vector is non-sharable, In this case even if I
indicate the NDIS to directly call my HandleInterruptHandler instead of
ISR
on receiving interrupt from the adapter does not help (not able to
schedule
the HandleInterruptHandler during the wait period).

I am not able to make out --What could be the possible reason for such
behavior from NDIS.
Could you please help me out of this ?

Regards,
Chirag Sanghani.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Steve Dispensa
Sent: Friday, July 02, 2004 11:53 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Problem of ISR and DPC in NDIS framework

On Fri, 2004-07-02 at 03:30, Chirag Sanghani wrote:

Driver

  1. Calls function f1 to send packet to card (called at
    DISPATCH_LEVEL).

Do you mean f1() is your MiniportSendPackets (or equivalent)? It
doesn’t have to be called at DISPATCH_LEVEL if that’s that’s the case,
for what that’s worth.

  1. Function f1 waits for Interrupt from hardware and
    “HandleInterruptHandler” to complete processing.

How does it wait? It’s illegal to wait at IRQL > APC_LEVEL, so I’m a
bit confused. Or do you mean that you create a new thread to wait from?

  1. Interrupt comes and sets the Flag TRUE for scheduling DPC
    “HandleInterruptHandler”(To run at Dispatch Level).

  2. Calling Function Endlessly waits for DPC “HandleInterruptHandler”
    to
    complete the processing, but DPC is not scheduled until calling
    function
    exits (I have set the timer for calling function to exit).

Are you just waiting for send confirmation or something? Is there a way
you can break this up and handle it more asynchronously? I think there
may be a cleaner design, if I understand this correctly.

Problem is DPC (which is called at DISPATCH_LEVEL) is not scheduled,
cause
some routine is already executing at Dispatch Level in driver.

Is my understanding is clear?
Can we some how execute the DPC even before the calling routine exits?

You can, of course, directly call your HandleInterruptHandler(), but I’m
not sure why you would want to. Again, I’m unclear on the architecture
of your driver. Could you provide some more detail?

-sd

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

You are currently subscribed to ntdev as: xxxxx@patni.com
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: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com