I’m experiencing the following problem when our NDIS IM driver is bound
to an nvidia miniport.
Everything works fine for a while, then suddenly all sends are accepted
(STATUS_PENDING) and never completed.
Our protocolReceivePacket routine is called normally (no
NDIS_STATUS_RESOURCES indication).
Thanks in advance for any insight.
PS: the driver doesn’t exhibit the behavior with miniports from other
vendors.
On 9/3/07, Andrei Zlate-Podani wrote: > > Hello, > > I’m experiencing the following problem when our NDIS IM driver is bound > to an nvidia miniport. > > Everything works fine for a while, then suddenly all sends are accepted > (STATUS_PENDING) and never completed. > Our protocolReceivePacket routine is called normally (no > NDIS_STATUS_RESOURCES indication). > > Thanks in advance for any insight. > > PS: the driver doesn’t exhibit the behavior with miniports from other > vendors. > > Andrei Zlate-Podani > > > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
chip nvidia chip is ths?
NVIDIA nForce 570 Ultra MCP
which os.
Windows XP 32 (tested by us), x64 & Vista (reported by our customers)
which driver version?
I’m testing with the latest (Ethernet Driver MCP55 v55.21). I used an
older version downloaded from Asus with the same results.
did u try latest drivers?
On 9/3/07, *Andrei Zlate-Podani* > mailto:xxxxx> wrote: > > Hello, > > I’m experiencing the following problem when our NDIS IM driver is > bound > to an nvidia miniport. > > Everything works fine for a while, then suddenly all sends are > accepted > (STATUS_PENDING) and never completed. > Our protocolReceivePacket routine is called normally (no > NDIS_STATUS_RESOURCES indication). > > Thanks in advance for any insight. > > PS: the driver doesn’t exhibit the behavior with miniports from other > vendors. > > Andrei Zlate-Podani > > > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > http: > > > — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging > and other seminars visit: http://www.osr.com/seminars To unsubscribe, > visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer</http:></mailto:xxxxx>
I found a solution to this issue. Our driver sent some packets and they
violated some assumptions of the miniport.
The nvidia miniport didn’t check (or did it incorrectly) the packet
protocol type (NDIS_GET_PACKET_PROTOCOL_TYPE) before using
the tcp offloading info. A packet that didn’t have a
NDIS_TCP_IP_CHECKSUM_PACKET_INFO apparently
blocked the processing of some internal queues until they were all used up.
Our hack involved setting the NDIS_TCP_IP_CHECKSUM_PACKET_INFO and the
NDIS_PROTOCOL_ID_TCP_IP type flag in the NDIS_PACKET structure.
are you sure that you see it on vista too? Can that be reconfirmed from your
customer?
On 9/4/07, Andrei Zlate-Podani wrote: > > Hello, > > I found a solution to this issue. Our driver sent some packets and they > violated some assumptions of the miniport. > The nvidia miniport didn’t check (or did it incorrectly) the packet > protocol type (NDIS_GET_PACKET_PROTOCOL_TYPE) before using > the tcp offloading info. A packet that didn’t have a > NDIS_TCP_IP_CHECKSUM_PACKET_INFO apparently > blocked the processing of some internal queues until they were all used > up. > > Our hack involved setting the NDIS_TCP_IP_CHECKSUM_PACKET_INFO and the > NDIS_PROTOCOL_ID_TCP_IP type flag in the NDIS_PACKET structure. > > Andrei > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >