Pankaj,
I don’t know for sure but I think this may vary depending on whether or not
your miniport is serialized or deserialized. AFAIK, a deserialized
miniport must ensure that all pending send (packets) are completed/aborted
and returned before returning from MiniportHalt. Likewise, AFAIK a
serialized miniport will *not* even be called at MiniportHalt until all
packets have been completed because the miniport logic in NDIS is keeping
track of sends, etc.
The best behavior in the MiniportHalt routine is, of course, to stall in
MiniportHalt until all packets have been returned. This works in any case.
To cleanup a packet that cannot be sent is driver specific, of course, but
essentially means taking it out of the send path processing and simply
completing it back to NDIS. If NDIS detects that a driver is having
problems sending, I believe it will call MiniportReset(). If your miniport
is prone to getting it’s nickers in knots then you should implement
MiniportCheckForHang() so that NDIS will know to call MiniportReset() when a
problem occurs.
In general a MAC driver should never retry a send. It is a layer 2 entity
and retrying a send is the responsibility of network layers above (session).
A MAC (miniport) is a best effort delivery mechanism. It is far better to
return the packet resources quickly and let upper layers deal with retry.
Good Luck,
Dave Cattley
David R. Cattley
Consulting Engineer
Systems Software Development
(whith special applogies to Greggory who will have to delete this mail by
hand…)
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pankaj Garg
Sent: Saturday, June 03, 2006 12:06 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS Miniport - MiniportHalt
Hi,
I have a curious situation in my NDIS Miniport driver. I want the driver to
be halted (right click disable from Network connections).
DDK says if I have some outstanding packets pending waiting to be
transmitted, I should finish them (return to upper layer) before leaving
MiniportHalt.
Sample drivers seem to implement this as well and this makes sense.
But in reality I don?t even get a call to my Halt function if I have packets
pending. The NDIS debugging techniques doc from Microsoft site tells how to
debug this problem and says that if you have packets outstanding then it may
not call your Halt function. You can see outstanding references in the
protocol by calling !miniports and !mopen and !protocol commands.
Which of these is correct? And if they will not call my halt function, and
lets say I have packets pending that have no way of going out (tx side
malfunction or something), then how will I clean up. I don?t see any mention
of retiring packets based on a timer. I also don?t get called for
CanceSendPackets.
Any clues?
-pankaj
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer