Hi Michal,
Thanx for the help, but i’m still facing the problem.
I’ve done some more testing and I’ve found this (i’ve used breakpoints also) :
The pointer to the packet that I queue shifts between the time that i queue and the next time I access the queue ( that is in the next send i get ).
The time it takes for this pointer value to change is dependent upon the protocol that I use, if I ues TCP/IP it changes almost immidately after I exit the send routine. With NetBEUI it takes some 2-3 sends after which I find that the value changes.
With HCT it changes consistently by shifting to +0xB0 everytime.
With WinME this problem doesn’t seem to be there.
Anybody has ANY idea as to why the pointer to the packet passed down is changing by itself and why the time it takes to change depends upon the upper protocol ?? ( i’m not manipulating the pointer to the packet, just queueing it ).
I’ll be grateful for any help whatsoever.
Thanx
Ramit.
----- Original Message -----
From: Vodicka, Michal
To: NT Developers Interest List
Sent: Friday, December 15, 2000 2:44 AM
Subject: [ntdev] RE: Protocol Packet Allocation
> From: Ramit Bhalla[SMTP:xxxxx@wipro.com]
> Reply To: NT Developers Interest List
> Sent: Thursday, December 14, 2000 07:37
> To: NT Developers Interest List
> Subject: [ntdev] RE: Protocol Packet Allocation
>
> Hi,
>
> I’m not setting the packet status to anything ( I don’t think that in a
> deserialized driver the upper layers check this according to the
> documentation it totally for personal use ) and I had even tried this
> strategy, but it didn’t work.
>
I meant status returned from you MiniportSend() handler.
>
> I’m also seeing one thing - I’m getting 2 sends simultaneously
>
It is possible for deserialized drivers especially on SMP machines.
>
> The 1st send acquires the lock and manipulates the list and queues the
> packets sent. Just after it releases the lock the context changes and the
> 2nd send starts manipulating the list and starts queueing the new packets,
> but for doing this I need to access the packets queued by the 1st send.
> When I try and access the packets queued by the first send, it panics or
> hangs, from debug messgaes and by using the debugger I find that the
> pointer to the packets are either corrupted( then it panics) otherwise If
> I debug step by step then it does not get corrupted but it hangs when I
> try and access the packets queued by the 1st send from the 2nd send’s
> context.
>
Seems as a bug somewhere in your code. You can try to use memory breakpoint
to see where is memory rewritten. BTW, which part of packet do you use for
queuing i.e. where do you store pointer to the next packet? MiniportReserved
should be used for this purpose.
>
> Anybody has any idea as to why this might be happening and is it possible
> to access the packets queued in the 1st (NDIS)send in the another
> (NDIS)send context ??
>
It is really possible to queue sent packets. At least it works in my driver
with no problem even when more sends occur at once 
Best regards,
Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]
You are currently subscribed to ntdev as: xxxxx@wipro.com
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