Hi ,
When I implement the IM driver , which is based on *DDK2003 Passthru
sample*, I oberseved that MiniportSendPackets() will be interrupted by
ProtocolReceive() .And sometime , MiniportSendPackets() will not begin to
run on the STOPPED point. For example , *the MiniportSendPackets() has
three steps: A->B->C->D. Sometimes if MiniportSendPackets() is interrupted
by ProtocolReceive() at step C, **and next time ,MiniportSendPackets()
will run from A, then B->C->D. Afther this ,then run from the stopped
point B. ** *
* I’m confused that ,does anyone have some clues ???*
I observed another one is that : the the IRQL of MiniportSendPackets()
sometimes is PASSIVE_LEVEL ,and somethimes is DISPATCH_LEVEL. I read the DDK
, which said “The MiniportSendPackets function of a deserialized miniport
can be called at any IRQL <= DISPATCH_LEVEL” ,
*My question is that “DO the IRQL of MiniportSendPackets() will be
changed on runtime ?”*
Best regards
Josephxu
MiniportSendPackets can be called at IRQL <= DISPATCH_LEVEL. If it is called at PASSIVE_LEVEL, it can be interrupted and some other code can execute at equal or higher IRQL. The behavior you see is because of deserialized nature of your driver.
Think of a scenario if two threads T1 and T2 are sending packets:
T1 sends a packet and your MiniportSendPackets is called.
You enter in MiniportSendPackets at PASSIVE_LEVEL.
You are executing and reached point B then suddenly network card got a packet and it interrupted the CPU
The physical adapter’s driver’s ISR will run and queue a DPC
The DPC will run and call your ProtocolReceive
In the meanwhile T2 also tried to send a packet
So your MiniportSendPackets is called again but now you are at point A
As you see, this can be totally random.
As for IRQL of MiniportSendPackets will be changed at runtime, well not in one call (unless some function change it explicitly). But as i said earlier, the system can call your MiniportSendPackets at different IRQL at different times.
–
Pankaj Garg
This posting is provided “AS IS” with no warranties and confers no rights.
“ze zefeng” wrote in message news:xxxxx@ntdev…
Hi ,
When I implement the IM driver , which is based on DDK2003 Passthru sample, I oberseved that MiniportSendPackets() will be interrupted by ProtocolReceive() .And sometime , MiniportSendPackets() will not begin to run on the STOPPED point. For example , the MiniportSendPackets() has three steps: A->B->C->D. Sometimes if MiniportSendPackets() is interrupted by ProtocolReceive() at step C, and next time ,MiniportSendPackets() will run from A, then B->C->D. Afther this ,then run from the stopped point B.
I’m confused that ,does anyone have some clues ???
I observed another one is that : the the IRQL of MiniportSendPackets() sometimes is PASSIVE_LEVEL ,and somethimes is DISPATCH_LEVEL. I read the DDK , which said “The MiniportSendPackets function of a deserialized miniport can be called at any IRQL <= DISPATCH_LEVEL” ,
My question is that “DO the IRQL of MiniportSendPackets() will be changed on runtime ?”
Best regards
Josephxu
Dear Pankaj Garg && Thomas
Thanks for your reply ,I get it 
Best regards
Josephxu
2006/2/9, Pankaj Garg :
>
> MiniportSendPackets can be called at IRQL <= DISPATCH_LEVEL. If it is
> called at PASSIVE_LEVEL, it can be interrupted and some other code can
> execute at equal or higher IRQL. The behavior you see is because of
> deserialized nature of your driver.
>
> Think of a scenario if two threads T1 and T2 are sending packets:
>
> T1 sends a packet and your MiniportSendPackets is called.
> You enter in MiniportSendPackets at PASSIVE_LEVEL.
> You are executing and reached point B then suddenly network card got a
> packet and it interrupted the CPU
> The physical adapter’s driver’s ISR will run and queue a DPC
> The DPC will run and call your ProtocolReceive
> In the meanwhile T2 also tried to send a packet
> So your MiniportSendPackets is called again but now you are at point A
>
> As you see, this can be totally random.
>
> As for IRQL of MiniportSendPackets will be changed at runtime, well not in
> one call (unless some function change it explicitly). But as i said earlier,
> the system can call your MiniportSendPackets at different IRQL at different
> times.
>
> –
> Pankaj Garg
> This posting is provided “AS IS” with no warranties and confers no rights.
>
>
>
> “ze zefeng” wrote in message news:xxxxx@ntdev…
> Hi ,
> When I implement the IM driver , which is based on DDK2003 Passthru
> sample, I oberseved that MiniportSendPackets() will be interrupted by
> ProtocolReceive() .And sometime , MiniportSendPackets() will not begin to
> run on the STOPPED point. For example , *the MiniportSendPackets() has
> three steps: A->B->C->D. Sometimes if MiniportSendPackets() is interrupted
> by ProtocolReceive() at step C, and next time ,MiniportSendPackets()
> will run from A, then B->C->D. Afther this ,then run from the stopped
> point B.
> * I’m confused that ,does anyone have some clues ???
>
> I observed another one is that : the the IRQL of
> MiniportSendPackets() sometimes is PASSIVE_LEVEL ,and somethimes is
> DISPATCH_LEVEL. I read the DDK , which said “The MiniportSendPackets
> function of a deserialized miniport can be called at any IRQL <=
> DISPATCH_LEVEL” ,
> My question is that “DO the IRQL of MiniportSendPackets() will be
> changed on runtime ?”
>
> Best regards
> Josephxu
>
>
> —
> 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
> I observed another one is that : the the IRQL of MiniportSendPackets()
sometimes is PASSIVE_LEVEL ,and somethimes is DISPATCH_LEVEL. I
read the DDK
, which said “The MiniportSendPackets function of a deserialized miniport
can be called at any IRQL <= DISPATCH_LEVEL” ,
So what? The doc is correct. <= DISPATCH means - sometimes DISPATCH, sometimes
PASSIVE, sometimes APC.
*My question is that "DO the IRQL of MiniportSendPackets() will be
How? You run at the IRQL you was called, unless you will acquire a spinlock.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com