>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.
I have also tried using NdisWaitEvent() with timeout = 0 and setting the
event from the HandleInterrutpHandler. However even in this case the
HandleInterruptHandler is not scheduled and the function f1() goes in an
indefinite wait loop.
- Why don’t you just return PENDING to the OID query and then when you
finally have a result, complete it via NdisMQueryInformationComplete.
Our architecture of establishment of calls demands that the call connection
procedure must be executed synchronously to avoid conflicts in multiple call
establishment.
Regards,
Chirag Sanghani.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Bryan Burgin
Sent: Saturday, July 03, 2004 11:18 AM
To: Windows System Software Devs Interest List
Cc: xxxxx@patni.com
Subject: RE: [ntdev] Problem of ISR and DPC in NDIS framework
-
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. -
Why don’t you just return PENDING to the OID query and then when you
finally have a result, complete it via NdisMQueryInformationComplete. -
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
- 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.
- 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?
Interrupt comes and sets the Flag TRUE for scheduling DPC
“HandleInterruptHandler”(To run at Dispatch Level).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
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