Deserialized miniport question
in [Device Drivers]
|
From: Jan on 1 May 2008 16:56 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
From: Pavel A. on 2 May 2008 10:07 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(a)discussions.microsoft.com> wrote in message news:EF754D63-D363-4BBB-9ED6-94CCD5A9C7AF(a)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 >
From: Jan on 2 May 2008 14:52 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(a)discussions.microsoft.com> wrote in message > news:EF754D63-D363-4BBB-9ED6-94CCD5A9C7AF(a)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 > > >
|
Pages: 1 Prev: Ramdisk with Vista SP1 Next: Howto increase NT kernel stack size? (if it is possible at all) |