> ----------
From: xxxxx@hotmail.com[SMTP:xxxxx@hotmail.com]
Reply To: xxxxx@lists.osr.com
Sent: Friday, February 22, 2002 11:53 AM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: MiniportReturnPacket() not getting called in NT
Deserialized miniport Driver
Anyone who can confirm or decline “deserialized” works ok in NT4 SP3+?
I can confirm. It is was introduced in SP3 and the only docs are ImSamp
sources and included document and ndis.h (and, of course, ndis.sys). There
were bugs in SP3 ndis.sys, for example Token Ring packet indication didn’t
work correctly (wrong deserialized handler), lock-up during boot when IM
driver was bound to several adapters and so on. Bugs were fixed in SP4 and
since then it works mostly without problems.
As I stated in another mail, there are some differences against w2k
implementation. It is always good idea to check ImSamp sources, compare with
w2k PassThru and prefer ImSamp way if differ. There were some bugs in ImSamp
and I don’t recall if all were fixed (I had such a driver written before
ImSamp release so only briefly read its sources and changed mine to
deserialized). Try to search news archives (groups.google.com) for ImSamp,
there are some messages from its author.
For all who want implement NDIS IM driver for NT4: ask yourself if it is
really necessary. Although deserialized drivers work there, they aren’t
officially documented and supported. You may encounter strange problems or
even bugs in NDIS. In such a case only good debugger and disassembler helps.
You’ll have to write very complicated INF file which can become nightmare
(ImSamp INF is a joke). Without good INF, all can “work” after installation
but breaks after rebinding later. And rebinding in NT4 can be caused by any
small change in network properties.
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.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
On Fri, 22 Feb 2002 21:29:17 +0100, Michal Vodicka
wrote:
> Yes, there
>are race conditions as you stated but it is unfortunately the only way
>because MiniportReturnPacket isn’t called for other than pending packets.
Note that there is actually a safe solution for this problem. You need
to implement an ‘Indicating’ flag in the ‘MiniportReserved’ area of
each packet indicated to NdisMIndicateReceivePacket(). Set the flag
before indicating the packet. In MiniportReturnPacket(), if the flag
is set, clear the flag and return immediately. This must be done with
a spin lock acquired!
When NdisMIndicateReceivePacket() returns, acquire the same spin lock.
Walk through the array of packets just indicated. If the ‘Indicating’
flag is still set, clear (set to NULL) the corresponding packet
pointer in the array. Otherwise, clear the flag. Release the spin
lock.
Now walk through the pointer array a second time. For all pointers !=
NULL, call MiniportReturnPacket().
HTH, Stephan
That one is actually documented somewhere in the DDK.
“Stephan Wolf” wrote in message news:xxxxx@ntdev…
>
> On Fri, 22 Feb 2002 21:29:17 +0100, Michal Vodicka
> wrote:
> > Yes, there
> >are race conditions as you stated but it is unfortunately the only way
> >because MiniportReturnPacket isn’t called for other than pending packets.
>
> Note that there is actually a safe solution for this problem. You need
> to implement an ‘Indicating’ flag in the ‘MiniportReserved’ area of
> each packet indicated to NdisMIndicateReceivePacket(). Set the flag
> before indicating the packet. In MiniportReturnPacket(), if the flag
> is set, clear the flag and return immediately. This must be done with
> a spin lock acquired!
>
> When NdisMIndicateReceivePacket() returns, acquire the same spin lock.
> Walk through the array of packets just indicated. If the ‘Indicating’
> flag is still set, clear (set to NULL) the corresponding packet
> pointer in the array. Otherwise, clear the flag. Release the spin
> lock.
>
> Now walk through the pointer array a second time. For all pointers !=
> NULL, call MiniportReturnPacket().
>
> HTH, Stephan
>
>
Hmm, yes, it used to be documented. I think it has been removed from
the docs, though.
Can someone point to the description of that solution in the docs?
Note that I already had and reported this solution before it got
documented. It is no longer necessary to use it in NDIS 5. It is only
necessary if you either definitely know you need to inspect the packet
‘Status’ after NdisMIndicateReceivePacket() returns, or if you’re not
sure if you should check it (NDIS 4.1 / NT4 problem).
Stephan
On Mon, 25 Feb 2002 08:52:51 -0800, “Scott Neugroschl”
wrote:
>
>That one is actually documented somewhere in the DDK.
>
>“Stephan Wolf” wrote in message news:xxxxx@ntdev…
>>
>> On Fri, 22 Feb 2002 21:29:17 +0100, Michal Vodicka
>> wrote:
>> > Yes, there
>> >are race conditions as you stated but it is unfortunately the only way
>> >because MiniportReturnPacket isn’t called for other than pending packets.
>>
>> Note that there is actually a safe solution for this problem. You need
>> to implement an ‘Indicating’ flag in the ‘MiniportReserved’ area of
>> each packet indicated to NdisMIndicateReceivePacket(). Set the flag
>> before indicating the packet. In MiniportReturnPacket(), if the flag
>> is set, clear the flag and return immediately. This must be done with
>> a spin lock acquired!
>>
>> When NdisMIndicateReceivePacket() returns, acquire the same spin lock.
>> Walk through the array of packets just indicated. If the ‘Indicating’
>> flag is still set, clear (set to NULL) the corresponding packet
>> pointer in the array. Otherwise, clear the flag. Release the spin
>> lock.
>>
>> Now walk through the pointer array a second time. For all pointers !=
>> NULL, call MiniportReturnPacket().
>>
>> HTH, Stephan
>>
>>
>
>
>
>
Using the downloadable version of the 2K DDK, it’s in:
Windows 2000 DDK => Network Drivers => Design Guide => Part 2: Miniport NIC
Drivers =>
4.6.1 Receiving Data/Multipacket Receives from Connectionless and
Connection-Oriented Miniports
“Stephan Wolf” wrote in message news:xxxxx@ntdev…
>
> Hmm, yes, it used to be documented. I think it has been removed from
> the docs, though.
>
> Can someone point to the description of that solution in the docs?
>
> Note that I already had and reported this solution before it got
> documented. It is no longer necessary to use it in NDIS 5. It is only
> necessary if you either definitely know you need to inspect the packet
> ‘Status’ after NdisMIndicateReceivePacket() returns, or if you’re not
> sure if you should check it (NDIS 4.1 / NT4 problem).
>
> Stephan
> —
> On Mon, 25 Feb 2002 08:52:51 -0800, “Scott Neugroschl”
> wrote:
>
> >
> >That one is actually documented somewhere in the DDK.
> >
> >“Stephan Wolf” wrote in message news:xxxxx@ntdev…
> >>
> >> On Fri, 22 Feb 2002 21:29:17 +0100, Michal Vodicka
> >> wrote:
> >> > Yes, there
> >> >are race conditions as you stated but it is unfortunately the only way
> >> >because MiniportReturnPacket isn’t called for other than pending
packets.
> >>
> >> Note that there is actually a safe solution for this problem. You need
> >> to implement an ‘Indicating’ flag in the ‘MiniportReserved’ area of
> >> each packet indicated to NdisMIndicateReceivePacket(). Set the flag
> >> before indicating the packet. In MiniportReturnPacket(), if the flag
> >> is set, clear the flag and return immediately. This must be done with
> >> a spin lock acquired!
> >>
> >> When NdisMIndicateReceivePacket() returns, acquire the same spin lock.
> >> Walk through the array of packets just indicated. If the ‘Indicating’
> >> flag is still set, clear (set to NULL) the corresponding packet
> >> pointer in the array. Otherwise, clear the flag. Release the spin
> >> lock.
> >>
> >> Now walk through the pointer array a second time. For all pointers !=
> >> NULL, call MiniportReturnPacket().
> >>
> >> HTH, Stephan
> >>
> >>
> >
> >
> >
> >
>
>
>
Yes, the description is there under the heading “Handling a Returned
Packet in the Context of the Receive Indication”.
The algorithm presented there uses two flags, but the overall idea is
the same.
Thanks for pointing that out!
Stephan
On Mon, 25 Feb 2002 11:15:17 -0800, “Scott Neugroschl”
wrote:
>
>Using the downloadable version of the 2K DDK, it’s in:
>
>Windows 2000 DDK => Network Drivers => Design Guide => Part 2: Miniport NIC
>Drivers =>
> 4.6.1 Receiving Data/Multipacket Receives from Connectionless and
>Connection-Oriented Miniports
>
>
>“Stephan Wolf” wrote in message news:xxxxx@ntdev…
>>
>> Hmm, yes, it used to be documented. I think it has been removed from
>> the docs, though.
>>
>> Can someone point to the description of that solution in the docs?
>>
>> Note that I already had and reported this solution before it got
>> documented. It is no longer necessary to use it in NDIS 5. It is only
>> necessary if you either definitely know you need to inspect the packet
>> ‘Status’ after NdisMIndicateReceivePacket() returns, or if you’re not
>> sure if you should check it (NDIS 4.1 / NT4 problem).
>>
>> Stephan
>> —
>> On Mon, 25 Feb 2002 08:52:51 -0800, “Scott Neugroschl”
>> wrote:
>>
>> >
>> >That one is actually documented somewhere in the DDK.
>> >
>> >“Stephan Wolf” wrote in message news:xxxxx@ntdev…
>> >>
>> >> On Fri, 22 Feb 2002 21:29:17 +0100, Michal Vodicka
>> >> wrote:
>> >> > Yes, there
>> >> >are race conditions as you stated but it is unfortunately the only way
>> >> >because MiniportReturnPacket isn’t called for other than pending
>packets.
>> >>
>> >> Note that there is actually a safe solution for this problem. You need
>> >> to implement an ‘Indicating’ flag in the ‘MiniportReserved’ area of
>> >> each packet indicated to NdisMIndicateReceivePacket(). Set the flag
>> >> before indicating the packet. In MiniportReturnPacket(), if the flag
>> >> is set, clear the flag and return immediately. This must be done with
>> >> a spin lock acquired!
>> >>
>> >> When NdisMIndicateReceivePacket() returns, acquire the same spin lock.
>> >> Walk through the array of packets just indicated. If the ‘Indicating’
>> >> flag is still set, clear (set to NULL) the corresponding packet
>> >> pointer in the array. Otherwise, clear the flag. Release the spin
>> >> lock.
>> >>
>> >> Now walk through the pointer array a second time. For all pointers !=
>> >> NULL, call MiniportReturnPacket().
>> >>
>> >> HTH, Stephan
>> >>
>> >>
>> >
>> >
>> >
>> >
>>
>>
>>
>
>
>
>