I face the same problem as Gopikrishna. but I don’t see any replies to his mail. Gopikrishna did U find a way out ?
Devs, any suggestions ?
Regards
Anandhi
Hi,
I have a problem in Deserialized miniport NIC driver in
Windows NT of MiniportReturnPacket() not getting called.
Before calling the NdisMIndicateReceivePacket() the status is set to NDIS_STATUS_SUCCESS.
As per the DDK for Win 2000 (NDIS 5), all the packet descriptors are returned by NDIS to Miniport driver through MiniportReturnPacket() function.
But the MiniPortReturnPacket() is never getting called for our driver.
We are assuming that the behavior in case of deserialized driver in WinNT (NDIS 4) is identical to the above.
Can anybody give some pointers for this problem ? Does anybody have the documentation for NDIS4 deserialized driver.
Thanx
Gopikrishna
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
NT4 w/o SP supports NDIS 4.0 only and thus does *not* support the
“deserialized” feature for NDIS Miniports. You need to use at least
NT4 SP3, which supports NDIS 4.1 and “deserialized”.
However, I am not sure “deserialized” is officially supported in NT4
at all. Thus, what you experience could be a bug in NDIS on NT4 SP3+.
Anyone who can confirm or decline “deserialized” works ok in NT4 SP3+?
Stephan
On 22 Feb 2002 09:40:18 -0000, “Anandhi” wrote:
>Hi all,=0A=0AI face the same problem as Gopikrishna. but I don’t see any re= >plies to his mail. Gopikrishna did U find a way out ?=0A=0ADevs, any sugges= >tions ?=0A=0ARegards=0AAnandhi=0A=0A=0AHi,=0A=0AI have a problem in Deseria= >lized miniport NIC driver in =0AWindows NT of MiniportReturnPacket() not ge= >tting called.=0ABefore calling the NdisMIndicateReceivePacket() the status = >is set to NDIS_STATUS_SUCCESS.=0A=0AAs per the DDK for Win 2000 (NDIS 5), a= >ll the packet descriptors are returned by NDIS to Miniport driver through M= >iniportReturnPacket() function.=0ABut the MiniPortReturnPacket() is never g= >etting called for our driver.=0A=0AWe are assuming that the behavior in cas= >e of deserialized driver in WinNT (NDIS 4) is identical to the above.=0A=0A= >=0A=0ACan anybody give some pointers for this problem ? Does anybody have t= >he documentation for NDIS4 deserialized driver.=0A=0A=0A=0AThanx=0AGopikris= >hna=0A=0A =0A
— You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’) To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
I ran into this problem as well in my NDIS Intermediate driver. I found the
answer in the ImSamp sample driver. It looks like there was a change made
between NDIS 4 and NDIS 5 with regards to NdisMIndicateReceivePacket().
Under NDIS 4, you need to check the packet status *AFTER* the call to
NdisMIndicateReceivePacket(). If the packet status is anything but
NDIS_STATUS_PENDING, no upper-level protocol has retained the packet and you
must dispose (or recycle) it appropriately. Your MiniportReturnPacket()
function will only be called if the packet status is NDIS_STATUS_PENDING
*AFTER* the call to NdisMIndicateReceivePacket().
Again this is different behavior is different from the NDIS 5 behavior where
the packet status after the call to NdisMIndicateReceivePacket() is
irrelevant.
I face the same problem as Gopikrishna. but I don’t see any replies to his mail. Gopikrishna did U find a way out ?
Devs, any suggestions ?
Regards Anandhi
Hi,
I have a problem in Deserialized miniport NIC driver in Windows NT of MiniportReturnPacket() not getting called. Before calling the NdisMIndicateReceivePacket() the status is set to NDIS_STATUS_SUCCESS.
As per the DDK for Win 2000 (NDIS 5), all the packet descriptors are returned by NDIS to Miniport driver through MiniportReturnPacket() function. But the MiniPortReturnPacket() is never getting called for our driver.
We are assuming that the behavior in case of deserialized driver in WinNT (NDIS 4) is identical to the above.
Can anybody give some pointers for this problem ? Does anybody have the documentation for NDIS4 deserialized driver.
Thanx Gopikrishna
— You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’) To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
— You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’) To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com</mailto:xxxxx>
Caution: The whole concept of NdisMIndicateReceivePacket() as well as
MiniportSendPackets() is IMHO dangerous. I reported to MS immediately
when they invented it. They didn’t realize I was right but changed
docs as well as functionality when they catched up.
The problem is that people get a wrong idea of how how things work
here.
When you pass up a packet to NdisMIndicateReceivePacket(), the packet
is out of your Miniport’s control. You actually release “ownership” of
the packet until NDIS passes the packet back to you.
Now when does NDIS pass you back “ownership” of the packet?
When NDIS calls MiniportReturnPacket(), the packet is clearly
re-owned by the Miniport. No doubt about it.
When the NdisMIndicateReceivePacket() call returns, the Miniport
shall inspect the ‘Status’ of each packet. If it’s PENDING, then NDIS
still owns the packet. Otherwise, the Miniport already owns the packet
again and MiniportReturnPacket() will not be called.
The missing part is that in a deserialized driver,
MiniportReturnPacket() can be called even before
NdisMIndicateReceivePacket() returns! That is, the packet passed up
might have been returned to the Miniport before it has a chance to
inspect the ‘Status’ member of any packet. The packet’s memory might
even have been freed already - boom!
MS finally also realized this and changed the docs to say that
deserialized Miniports must not check the packet ‘Status’ after a call
to NdisMIndicateReceivePacket().
Now if you’re running on NT4 with an NDIS.SYS that does *not* support
deserialized, NDIS handles your Miniport as “serialized” but you think
you’re actually running deserialized. Because you set the
NDIS_ATTRIBUTE_DESERIALIZE flag, which NDIS ignores. And the conflict
is exactly that you think you do not need to or even must not inspect
the ‘Status’ while NDIS expects you to.
I hope you understand what I’m saying. This isn’t trivial, I know.
Stephan
On Fri, 22 Feb 2002 08:31:09 -0800, “Ed Reed”
wrote:
>I ran into this problem as well in my NDIS Intermediate driver. I found the >answer in the ImSamp sample driver. It looks like there was a change made >between NDIS 4 and NDIS 5 with regards to NdisMIndicateReceivePacket(). >Under NDIS 4, you need to check the packet status AFTER the call to >NdisMIndicateReceivePacket(). If the packet status is anything but >NDIS_STATUS_PENDING, no upper-level protocol has retained the packet and you >must dispose (or recycle) it appropriately. Your MiniportReturnPacket() >function will only be called if the packet status is NDIS_STATUS_PENDING >AFTER the call to NdisMIndicateReceivePacket(). > >Again this is different behavior is different from the NDIS 5 behavior where >the packet status after the call to NdisMIndicateReceivePacket() is >irrelevant. > >– >Ed Reed mailto:xxxxx >Connectix Corporation > >“Anandhi” wrote in message news:xxxxx@ntdev… > > >Hi all, > >I face the same problem as Gopikrishna. but I don’t see any replies to his >mail. Gopikrishna did U find a way out ? > >Devs, any suggestions ? > >Regards >Anandhi > > >Hi, > >I have a problem in Deserialized miniport NIC driver in >Windows NT of MiniportReturnPacket() not getting called. >Before calling the NdisMIndicateReceivePacket() the status is set to >NDIS_STATUS_SUCCESS. > >As per the DDK for Win 2000 (NDIS 5), all the packet descriptors are >returned by NDIS to Miniport driver through MiniportReturnPacket() function. >But the MiniPortReturnPacket() is never getting called for our driver. > >We are assuming that the behavior in case of deserialized driver in WinNT >(NDIS 4) is identical to the above. > > > >Can anybody give some pointers for this problem ? Does anybody have the >documentation for NDIS4 deserialized driver. > > > >Thanx >Gopikrishna
— You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’) To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com</mailto:xxxxx>