Deserialized miniport question

Hi,

I am leveraging a deserialized miniport driver that hooks into the NDIS
library. The driver is written in WDM format, not in WDF, and the OS is
Windows XP

The miniport driver hooks into the Windows TCP/IP stack and uses my hardware
driver to send and receive data across the physical medium. The hardware is
a PCIe Non-transparent bridge.

I have successfully connected on a HARDWARE level, and am able to transfer
data back and forth between the processors' exposed memory.

Consider:
Processor A = Windows XP = miniport Driver.
Processor B = other side of the NTB PCIe chip.

Processor A boots first, and establishes the connections as far as it can.
When Processor B boots, it sends a GRATUITOUS ARP to Processor A through my
hardware and miniport driver.

1) From what I can tell, the ARP comes across from B to A, and I can see it
in Wireshark when I monitor my adapter. HOWEVER, the ARP information does
not get logged into the ARP table, even when I â??preloadâ?? the table with the
IP and a bogus Physical Address. I was expecting the Physical Address to get
updated with the GRATUITOUS ARP, but it doesnâ??t.

2) Data from the GRATUITOUS ARP is passed up to the Windows stack via a call
to NDISMIndicateReceivePacket() in my minport driver, and I can see my
MiniportReturnPacket() function get called to release the packet.

3) Next, when I try to â??pingâ?? Processor B from Processor A, I can see the
ping request come across into Processor B, and then see B respond back to A.
I see the data come through into the miniport driver, but it all hangs when
NdisMIndicateReceivePacket() is called. There is no Blue screen of Death,
but it might as well, because it all hangs. It BEHAVES as if the system is
locked on a spin lock, but I donâ??t think that is it. I can comment in and
out the NdisMIndicateReceivePacket( ) to change behavior.

The OOB data packet status is set to:
NDIS_SET_PACKET_STATUS(RecvPacket, NDIS_STATUS_SUCCESS);

Prior to calling NdisMIndicateReceivePacket().

I am looking for ideas on what to look into as possible suspects. Does
anyone have any thoughts?

Thanks,

Jan

Pavel
Fri May 02 09:07:05 CDT 2008

So do you think that these two problems ( the gratituos arp not catched and
the hang in receive path)
are independent or not? Maybe it would help if you fix the receive path
first.

--PA


"Jan" <Jan@discussions.microsoft.com> wrote in message
news:EF754D63-D363-4BBB-9ED6-94CCD5A9C7AF@microsoft.com...
> Hi,
>
> I am leveraging a deserialized miniport driver that hooks into the NDIS
> library. The driver is written in WDM format, not in WDF, and the OS is
> Windows XP
>
> The miniport driver hooks into the Windows TCP/IP stack and uses my
> hardware
> driver to send and receive data across the physical medium. The hardware
> is
> a PCIe Non-transparent bridge.
>
> I have successfully connected on a HARDWARE level, and am able to transfer
> data back and forth between the processors' exposed memory.
>
> Consider:
> Processor A = Windows XP = miniport Driver.
> Processor B = other side of the NTB PCIe chip.
>
> Processor A boots first, and establishes the connections as far as it can.
> When Processor B boots, it sends a GRATUITOUS ARP to Processor A through
> my
> hardware and miniport driver.
>
> 1) From what I can tell, the ARP comes across from B to A, and I can see
> it
> in Wireshark when I monitor my adapter. HOWEVER, the ARP information does
> not get logged into the ARP table, even when I â??preloadâ?? the table
> with the
> IP and a bogus Physical Address. I was expecting the Physical Address to
> get
> updated with the GRATUITOUS ARP, but it doesnâ??t.
>
> 2) Data from the GRATUITOUS ARP is passed up to the Windows stack via a
> call
> to NDISMIndicateReceivePacket() in my minport driver, and I can see my
> MiniportReturnPacket() function get called to release the packet.
>
> 3) Next, when I try to â??pingâ?? Processor B from Processor A, I can see
> the
> ping request come across into Processor B, and then see B respond back to
> A.
> I see the data come through into the miniport driver, but it all hangs
> when
> NdisMIndicateReceivePacket() is called. There is no Blue screen of Death,
> but it might as well, because it all hangs. It BEHAVES as if the system
> is
> locked on a spin lock, but I donâ??t think that is it. I can comment in
> and
> out the NdisMIndicateReceivePacket( ) to change behavior.
>
> The OOB data packet status is set to:
> NDIS_SET_PACKET_STATUS(RecvPacket, NDIS_STATUS_SUCCESS);
>
> Prior to calling NdisMIndicateReceivePacket().
>
> I am looking for ideas on what to look into as possible suspects. Does
> anyone have any thoughts?
>
> Thanks,
>
> Jan
>

Jan
Fri May 02 13:52:00 CDT 2008

Agreed, a good suggestion. Thank you for responding!

I found my issue, and it WAS indeed a spin lock problem. You must release
all spin locks before calling NdisMIndicateReceivePacket(). I was doing (and
verifying) this in the miniport driver, but not at a layer below the
miniport. Once I released all spin locks, the problem was resolved. The ARP
table is getting updated properly, AND I can ping back and forth.

Thanks,

Jan

"Pavel A." wrote:

> So do you think that these two problems ( the gratituos arp not catched and
> the hang in receive path)
> are independent or not? Maybe it would help if you fix the receive path
> first.
>
> --PA
>
>
> "Jan" <Jan@discussions.microsoft.com> wrote in message
> news:EF754D63-D363-4BBB-9ED6-94CCD5A9C7AF@microsoft.com...
> > Hi,
> >
> > I am leveraging a deserialized miniport driver that hooks into the NDIS
> > library. The driver is written in WDM format, not in WDF, and the OS is
> > Windows XP
> >
> > The miniport driver hooks into the Windows TCP/IP stack and uses my
> > hardware
> > driver to send and receive data across the physical medium. The hardware
> > is
> > a PCIe Non-transparent bridge.
> >
> > I have successfully connected on a HARDWARE level, and am able to transfer
> > data back and forth between the processors' exposed memory.
> >
> > Consider:
> > Processor A = Windows XP = miniport Driver.
> > Processor B = other side of the NTB PCIe chip.
> >
> > Processor A boots first, and establishes the connections as far as it can.
> > When Processor B boots, it sends a GRATUITOUS ARP to Processor A through
> > my
> > hardware and miniport driver.
> >
> > 1) From what I can tell, the ARP comes across from B to A, and I can see
> > it
> > in Wireshark when I monitor my adapter. HOWEVER, the ARP information does
> > not get logged into the ARP table, even when I ââ?¬Ë?preloadââ?¬â?¢ the table
> > with the
> > IP and a bogus Physical Address. I was expecting the Physical Address to
> > get
> > updated with the GRATUITOUS ARP, but it doesn�t.
> >
> > 2) Data from the GRATUITOUS ARP is passed up to the Windows stack via a
> > call
> > to NDISMIndicateReceivePacket() in my minport driver, and I can see my
> > MiniportReturnPacket() function get called to release the packet.
> >
> > 3) Next, when I try to ââ?¬Ë?pingââ?¬â?¢ Processor B from Processor A, I can see
> > the
> > ping request come across into Processor B, and then see B respond back to
> > A.
> > I see the data come through into the miniport driver, but it all hangs
> > when
> > NdisMIndicateReceivePacket() is called. There is no Blue screen of Death,
> > but it might as well, because it all hangs. It BEHAVES as if the system
> > is
> > locked on a spin lock, but I don�t think that is it. I can comment in
> > and
> > out the NdisMIndicateReceivePacket( ) to change behavior.
> >
> > The OOB data packet status is set to:
> > NDIS_SET_PACKET_STATUS(RecvPacket, NDIS_STATUS_SUCCESS);
> >
> > Prior to calling NdisMIndicateReceivePacket().
> >
> > I am looking for ideas on what to look into as possible suspects. Does
> > anyone have any thoughts?
> >
> > Thanks,
> >
> > Jan
> >
>