FW: Ndisallocatepacket failing

NTDEV
1

RE: [ntdev] Ndisallocatepacket failing

Hi Alan

one more thing i forgot to point out was that
u got it abosultely right in guessing that my
send function was being called from the receive
indicate handler.

The other thing to point out is that i have counted the allocs and frees
and they become mismatched ie the allocs exceed the frees when this
problem occurs.

Also i found out another way of quickly arriving at the problem. When the
application
sitting in the user mode ( which has a open handle to the drriver ) is
exited using ctrl C, then the underlying driver
come up with the problem. In this ctrl C case, the drivers PacketClose
functions is called.
In this what i see is that after the application has exited using ctrl C,
the alloc are getting called,
but the sendcomplete handler stops getting called and thus again the problem
occurs
and a mismatch occurs in the allocs and frees.

regds
Mayank

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Alan Kan
Sent: Tuesday, May 11, 2004 1:42 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Ndisallocatepacket failing

A few points:

  1. Your code looks fine without queuing.
  2. The queuing issue I mentioned in my pseudo code was something I have
    seen that caused a race condition leading to leaking of NDIS packet
    resources, which I thought may be causing your problem. The queuing was
    needed for a number of reasons in that particular application, but may not
    apply to your case. For example, queuing can be employed to detect
    out-of-order packet completion, for sanity checking, or is needed when this
    is the protocol half of an intermediate driver that needs to perform packet
    processing.
  3. Are you binding to a stock hardware NIC driver or is it your NIC driver
    as well? What I’m getting at is, do you see a matching number of
    SendCompleteHandler() calls as the number of NdisSend() calls you make?
  4. The code as it is shown should not have any problems being called
    multiple times by multiple threads, as there are no shared data shown.
    However, as this is probably just a skeleton of your actual driver you may
    want to double check if there are any shared data structure being accessed
    between the SendFunction() and the SendComplete() function that may
    contribute to a race condition.
  5. The fact that you are seeing this allocate failure easily with SoftICE
    breakpointing is something to ponder with respect to the underlying NIC
    driver completing the packets. If the underlying NIC driver is a stock
    hardware driver, you might consider changing the network card (thus a
    different NIC driver) to see if the behavior changes, and hopefully get more
    clues.

Hope it helps.

Alan Kan
xxxxx@flyingeaglesoftware.com

2

Hi Mayank,
I understand what you wrote re: Ctrl-C issue but cannot really further
comment without making up lots of assumptions, in which case maybe we can
take the discussion off-line. The symptom is that somehow you are not
getting SendComplete()'s when you should have. Since the SendComplete()
originates from the underlying NIC driver, can you tell me more about the
underlying network configuration? What kind of hardware is it,
plain-o-Ethernet? You can email me if you so desire.

Regards,
Alan Kan
xxxxx@flyingeaglesoftware.com

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mayank Kumar
Sent: Tuesday, May 11, 2004 4:21 AM
To: Windows System Software Devs Interest List
Subject: FW: [ntdev] Ndisallocatepacket failing

Hi Alan

one more thing i forgot to point out was that
u got it abosultely right in guessing that my
send function was being called from the receive
indicate handler.

The other thing to point out is that i have counted the allocs and frees
and they become mismatched ie the allocs exceed the frees when this
problem occurs.

Also i found out another way of quickly arriving at the problem. When the
application
sitting in the user mode ( which has a open handle to the drriver ) is
exited using ctrl C, then the underlying driver
come up with the problem. In this ctrl C case, the drivers PacketClose
functions is called.
In this what i see is that after the application has exited using ctrl C,
the alloc are getting called,
but the sendcomplete handler stops getting called and thus again the problem
occurs
and a mismatch occurs in the allocs and frees.

regds
Mayank

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Alan Kan
Sent: Tuesday, May 11, 2004 1:42 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Ndisallocatepacket failing

A few points:

  1. Your code looks fine without queuing.
  2. The queuing issue I mentioned in my pseudo code was something I have seen
    that caused a race condition leading to leaking of NDIS packet resources,
    which I thought may be causing your problem. The queuing was needed for a
    number of reasons in that particular application, but may not apply to your
    case. For example, queuing can be employed to detect out-of-order packet
    completion, for sanity checking, or is needed when this is the protocol half
    of an intermediate driver that needs to perform packet processing.
  3. Are you binding to a stock hardware NIC driver or is it your NIC driver
    as well? What I’m getting at is, do you see a matching number of
    SendCompleteHandler() calls as the number of NdisSend() calls you make?
  4. The code as it is shown should not have any problems being called
    multiple times by multiple threads, as there are no shared data shown.
    However, as this is probably just a skeleton of your actual driver you may
    want to double check if there are any shared data structure being accessed
    between the SendFunction() and the SendComplete() function that may
    contribute to a race condition.
  5. The fact that you are seeing this allocate failure easily with SoftICE
    breakpointing is something to ponder with respect to the underlying NIC
    driver completing the packets. If the underlying NIC driver is a stock
    hardware driver, you might consider changing the network card (thus a
    different NIC driver) to see if the behavior changes, and hopefully get more
    clues.

Hope it helps.

Alan Kan
xxxxx@flyingeaglesoftware.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@flyingeaglesoftware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com