Dietmar

@reboot12 I send you a new driver in 5 min. Use also the new KD Block Dietmar

@reboot12 Ok, Tx (means sending) is now up. But Rx (receive) still down. Here is next KD block for to check registers. Ping both compis each other and to router Dietmar sxd ud bc * bu i219!I219TxRxStart "r @$t7=poi(poi(@esp+4)+0xDC); .printf \"REGS=%p\n\", @$t7; gc" bu i219!I219MiniportHandleInterrupt ".echo HINT; dd @$t7+0x0008 L1; dd @$t7+0x2810 L1; dd @$t7+0x2818 L1; dd @$t7+0x3810 L1; dd @$t7+0x3818 L1; gc" bu i219!I219MiniportSendPackets "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .printf \"SEND_IN CNT=%u regs=%p\n\", poi(@esp+0x0c), $t1; bp /1 @$t2 \".echo SEND_OUT; dd @$t7+0x0008 L1; dd @$t7+0x2810 L1; dd @$t7+0x2818 L1; dd @$t7+0x3810 L1; dd @$t7+0x3818 L1; gc\"; gc" bu ndis!EthFilterDprIndicateReceive ".echo NDIS_RX; gc" bu ndis!EthFilterDprIndicateReceiveComplete ".echo NDIS_RXC; gc" g

@reboot12 Let the compi, where not Windbg runs, go until to the desktop. For this you need the full KD block, last time you cancelled the first line. Very funny, your router makes now 100 MB, but my falls back to 10MB. Anyway, ping from your compi, where Windbg NOT runs your router. And ping also from the compi, where Windbg runs, your debugged compi Dietmar sxd ud bc * bu i219!I219MiniportHandleInterrupt ".echo HINT; gc" bu i219!I219MiniportSendPackets "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"SEND CNT=%u regs=%p\n\", poi(@esp+0x0c), $t1; dd $t1+0x0008 L1; dd $t1+0x3808 L1; dd $t1+0x3810 L1; dd $t1+0x3818 L1; dd $t1+0x3828 L1; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"RXPOLL regs=%p\n\", $t1; dd $t1+0x0008 L1; dd $t1+0x0100 L1; dd $t1+0x2800 L3; dd $t1+0x2810 L1; dd $t1+0x2818 L1; dd $t1+0x2828 L1; gc" bu ndis!EthFilterDprIndicateReceive ".echo NDIS_RX; gc" bu ndis!EthFilterDprIndicateReceiveComplete ".echo NDIS_RXC; gc" g

@reboot12 Here is the next driver, version v1l. And make use of this new KD block, good luck Dietmar https://www.upload.ee/files/19114850/i219v1l.zip.html sxd ud bc * bu i219!I219MiniportInitialize ".echo INIT; gc" bu i219!I219DoCtrlKickLate "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .echo CTRLKICK_IN; .printf \"regs=%p ret=%p\n\", $t1, $t2; dd $t1+0x0000 L1; dd $t1+0x0008 L1; dd $t1+0x0018 L1; bp /1 @$t2 \".echo CTRLKICK_OUT; dd @$t1+0x0000 L1; dd @$t1+0x0008 L1; dd @$t1+0x0018 L1; gc\"; gc" bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .echo TXRX_IN; .printf \"regs=%p ret=%p\n\", $t1, $t2; dd $t1+0x0100 L1; dd $t1+0x0400 L1; dd $t1+0x2800 L3; dd $t1+0x2810 L1; dd $t1+0x2818 L1; dd $t1+0x2828 L1; dd $t1+0x3800 L3; dd $t1+0x3810 L1; dd $t1+0x3818 L1; dd $t1+0x3828 L1; bp /1 @$t2 \".echo TXRX_OUT; dd @$t1+0x0100 L1; dd @$t1+0x0400 L1; dd @$t1+0x2800 L3; dd @$t1+0x2810 L1; dd @$t1+0x2818 L1; dd @$t1+0x2828 L1; dd @$t1+0x3800 L3; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; gc\"; gc" bu i219!I219MiniportHandleInterrupt ".echo HINT; gc" bu i219!I219MiniportSendPackets "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"SEND CNT=%u regs=%p\n\", poi(@esp+0x0c), $t1; dd $t1+0x3808 L1; dd $t1+0x3810 L1; dd $t1+0x3818 L1; dd $t1+0x3828 L1; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"RXPOLL regs=%p\n\", $t1; dd $t1+0x0100 L1; dd $t1+0x2800 L3; dd $t1+0x2810 L1; dd $t1+0x2818 L1; dd $t1+0x2828 L1; gc" bu ndis!EthFilterDprIndicateReceive ".echo NDIS_RX; gc" bu ndis!EthFilterDprIndicateReceiveComplete ".echo NDIS_RXC; gc" g

@reboot12 Yes, I go back to my very first working driver v1. Yes — this is the best log so far. It gives you a direct code-level culprit. The biggest advantage We now see that I219PhyEnsureAutonegAll() is the function that is crippling the PHY advertisement. From the MDIC writes: It reads reg 4 (ANAR) and gets 0x0d01 Then it writes reg 4 back as 0x0d01 It reads reg 9 (GBCR) and gets 0x0000 Then it writes reg 9 back as 0x0000 It reads reg 0 (BMCR) and gets 0x3100 Then it writes reg 0 as 0x3300 (basically “restart autoneg” on top of the old state) That means: ANAR = 0x0d01 = not “all”; it is effectively a crippled 10/100 advertisement, and in practice you are landing on 100 Mb FD GBCR = 0x0000 = no 1000BASE-T advertisement at all Then autoneg is restarted with that crippled advertisement So the function named EnsureAutonegAll is not actually enabling all modes on this machine. That exactly matches the observed link: LinkState -> UP 100Mb FD Second big result TXRX_OUT proves the ring programming is correct: RCTL = 04008012 → RX enabled RDBAL = 0x0aa9b100 → matches allocated RX desc physical address RDLEN = 0x00000100 → 16 descriptors × 16 bytes = correct RDH = 0 RDT = 0x0f → tail posted correctly RXDCTL = 03040420 → queue enabled/configured TDBAL = 0x0aa9b000 → matches TX desc physical address TDLEN = 0x00000100 → correct So: RX/TX setup code is fine Descriptor base/length/tail are fine the failure is not in ring initialization What this means now You now have two separate facts: PHY advertisement is wrong by code Your driver is explicitly leaving: no gigabit advertisement reduced 10/100 advertisement Even after correct ring setup, RDH stays 0 So frames still are not being DMA’d into RX descriptors The first one is now a clear, concrete bug I can patch immediately. The most likely next fix The first place to patch is I219PhyEnsureAutonegAll(). For a test build, it should force proper autoneg advertisement, not preserve the broken values. What it should roughly do: ANAR: advertise normal 10/100 capabilities, not just the current crippled set A good test value is 0x0DE1 (10/100 half/full + pause/selector) GBCR: advertise 1000 Full A good test value is at least 0x0200 BMCR: restart autoneg in a clean way Better to use a clean autoneg state than preserve the old forced bits So the current logic: “read current ANAR/GBCR” “write them back unchanged” “restart autoneg” is very likely wrong on this LM/15BB board. One more useful clue CTRLKICK_OUT changes: CTRL from 00180240 to 00100240 register at 0x0018 from 815a1027 to 915a1027 So the ME-guard / ctrlkick path is doing something real, not nothing. That is good: the handoff path is active. The main problem is now much more likely the PHY programming values, means Power Saving. I make a new driver and send to you Dietmar

@reboot12 The 100MB connection is not the problem. Yes, I force this chip to enable not 10MB. But it is for sure the low power setting, which works through a lot of bits, see Linux problems. And for this is the KD block above, which register is set and which not. If you want to make your driver work or just for to understand what is going on, lets continue Dietmar

@reboot12 I just check your 2 logs. Everything is setup correct, only to send and to get does not work. When I look at the Linux Source code e1000e for the i219-LM they fight with the same problem. Intel itself tells, that it does not know, why this chip sometimes remain in some kind of a sleeping state. I run the same driver and the same KD block on my i219, so I can see the differences clear. Here is a new KD block for the v1k version, please test Dietmar bc * bu i219!I219MiniportInitialize ".echo INIT; gc" bu i219!I219DoCtrlKickLate "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .echo CTRLKICK_IN; .printf \"regs=%p ret=%p\n\", $t1, $t2; dd $t1+0x0000 L1; dd $t1+0x0008 L1; dd $t1+0x0018 L1; dd $t1+0x0020 L1; bp /1 @$t2 \".echo CTRLKICK_OUT; dd @$t1+0x0000 L1; dd @$t1+0x0008 L1; dd @$t1+0x0018 L1; dd @$t1+0x0020 L1; gc\"; ba w4 (@$t1+0x20) \".echo MDIC_W; dd @$t1+0x0020 L1; kb 3; gc\"; gc" bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .echo TXRX_IN; .printf \"regs=%p ret=%p\n\", $t1, $t2; dd $t1+0x0100 L1; dd $t1+0x0400 L1; dd $t1+0x2800 L3; dd $t1+0x2810 L1; dd $t1+0x2818 L1; dd $t1+0x2828 L1; dd $t1+0x3800 L3; dd $t1+0x3810 L1; dd $t1+0x3818 L1; dd $t1+0x3828 L1; bp /1 @$t2 \".echo TXRX_OUT; dd @$t1+0x0100 L1; dd @$t1+0x0400 L1; dd @$t1+0x2800 L3; dd @$t1+0x2810 L1; dd @$t1+0x2818 L1; dd @$t1+0x2828 L1; dd @$t1+0x3800 L3; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; gc\"; gc" bu i219!I219MiniportHandleInterrupt ".echo HINT; gc" bu i219!I219MiniportSendPackets "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"SEND CNT=%u regs=%p\n\", poi(@esp+0x0c), $t1; dd $t1+0x3810 L1; dd $t1+0x3818 L1; dd $t1+0x3828 L1; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"RXPOLL regs=%p\n\", $t1; dd $t1+0x0100 L1; dd $t1+0x2800 L3; dd $t1+0x2810 L1; dd $t1+0x2818 L1; dd $t1+0x2828 L1; gc" bu ndis!EthFilterDprIndicateReceive ".echo NDIS_RX; gc" bu ndis!EthFilterDprIndicateReceiveComplete ".echo NDIS_RXC; gc" g

@reboot12 And here is the next one, very close to the Linux PowerSave problem. Type that in one block in KD Dietmar https://www.upload.ee/files/19113237/i219v1k.zip.html !sym quiet bc * bu i219!I219MiniportInitialize ".echo INIT; gc" bu i219!I219DoCtrlKickLate "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo CTRLKICK; .printf \"regs=%p\n\", $t1; dd $t1+0x0000 L1; dd $t1+0x0008 L1; dd $t1+0x0018 L1; gc" bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRXSTART; .printf \"regs=%p\n\", $t1; dd $t1+0x0000 L1; dd $t1+0x0008 L1; dd $t1+0x0100 L1; dd $t1+0x2808 L1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; dd $t1+0x2828 L1; dd $t1+0x3808 L1; dd $t1+0x3810 L1; dd $t1+0x3818 L1; gc" bu i219!I219MiniportHandleInterrupt ".echo HINT; gc" bu i219!I219MiniportSendPackets "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"SEND CNT=%u regs=%p\n\", poi(@esp+0x0c), $t1; dd $t1+0x3810 L1; dd $t1+0x3818 L1; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"RXPOLL regs=%p\n\", $t1; dd $t1+0x0100 L1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; dd $t1+0x2828 L1; gc" bu ndis!EthFilterDprIndicateReceive ".echo NDIS_RX; gc" bu ndis!EthFilterDprIndicateReceiveComplete ".echo NDIS_RXC; gc" g

@reboot12 Here is the next best i219-LM version for you. Your log shows, that something wakes up ;)).. And use new KD block also https://www.upload.ee/files/19112515/i219v1h.zip.html bc * bu i219!I219MiniportHandleInterrupt ".echo HINT; gc" bu i219!I219TxRxStart ".echo TXRXSTART; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"RXPOLL regs=%p\n\", $t1; dd $t1+0x0100 L1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; dd $t1+0x2828 L1; gc" bu i219!I219MiniportSendPackets ".printf \"SEND CNT=%u\n\", poi(@esp+0x0c); gc" bu ndis!EthFilterDprIndicateReceive ".echo NDIS_RX; gc" g

@reboot12 Please check this last driver with KD commands that I give to you. Because I found a Linux forum entry with exact your symptoms and cure for it Dietmar

@reboot12 here it is, good luck Dietmar https://www.upload.ee/files/19112373/i219v1g.zip.html

@reboot12 Ok, I make a very last driver i219 for you for today. Use this KD commands Dietmar !sym quiet bc * bu i219!I219MiniportInitialize ".echo INIT; gc" bu i219!I219DoCtrlKickLate "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo CTRLKICK; .printf \"regs=%p\\n\", $t1; dd $t1+0x0000 L1; dd $t1+0x0008 L1; dd $t1+0x0018 L1; gc" bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRXSTART; .printf \"regs=%p\\n\", $t1; dd $t1+0x0000 L1; dd $t1+0x0008 L1; dd $t1+0x0100 L1; dd $t1+0x2808 L1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; dd $t1+0x2828 L1; dd $t1+0x3808 L1; dd $t1+0x3810 L1; dd $t1+0x3818 L1; gc" bu i219!I219MiniportHandleInterrupt ".echo HINT; gc" bu i219!I219MiniportSendPackets "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"SEND CNT=%u regs=%p\\n\", poi(@esp+0x0c), $t1; dd $t1+0x3810 L1; dd $t1+0x3818 L1; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"RXPOLL regs=%p\\n\", $t1; dd $t1+0x0100 L1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; dd $t1+0x2828 L1; gc" bu ndis!EthFilterDprIndicateReceive ".echo NDIS_RX; gc" bu ndis!EthFilterDprIndicateReceiveComplete ".echo NDIS_RXC; gc" g

@reboot12 This is the last version for today, because I have no more ideas just now. Use this new KD commands in one block. Dietmar https://www.upload.ee/files/19112279/i219PowerOn.zip.html bc * bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"TXRXSTART regs=%p\n\", $t1; dd $t1+0x5b50 L1; dd $t1+0x5b54 L1; dd $t1+0x5b58 L1; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"RXPOLL regs=%p\n\", $t1; dd $t1+0x0100 L1; dd $t1+0x2828 L1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; gc" bu i219!I219MiniportSendPackets ".printf \"SEND CNT=%u\n\", poi(@esp+0x0c); gc" bu ndis!EthFilterDprIndicateReceive ".echo NDIS_RX; gc" bu ndis!EthFilterDprIndicateReceiveComplete ".echo NDIS_RXC; gc" g

@reboot12 Here it is. https://www.upload.ee/files/19112222/i219RDH.zip.html Use the KD commands from above in one block. Good luck Dietmar

@reboot12 This is from my thinking a PHY/MAC power-state issue. After TxRxStart OK, you have: RXDCTL = 03040420 RDT = 0000000f but RDH = 00000000 forever I tested my original i219 driver for XP SP3 on such a lot of different motherboards, include the i219-LM with the same Dev_15BB that you have. All work. I make you one more i219 driver in 5min, because I hope that I can overcome this RDH = 00000000 forever Dietmar bc * bu i219!I219MiniportHandleInterrupt ".echo HINT; gc" bu i219!I219MiniportSendPackets "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"SEND CNT=%u regs=%p\n\", poi(@esp+0x0c), $t1; dd $t1+0x3810 L1; dd $t1+0x3818 L1; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"RXPOLL regs=%p\n\", $t1; dd $t1+0x0100 L1; dd $t1+0x2828 L1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; gc" bu ndis!EthFilterDprIndicateReceive ".echo NDIS_RX; gc" bu ndis!EthFilterDprIndicateReceiveComplete ".echo NDIS_RXC; gc" g

@reboot12 Here is next one and use this new KD commands in one block. Type g when it stops https://www.upload.ee/files/19112130/I219dontstopPoll.zip.html bc * bu i219!I219MiniportHandleInterrupt "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo HINT; dd $t1+0x2810 L1; dd $t1+0x2818 L1; dd $t1+0x3810 L1; dd $t1+0x3818 L1; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"RXPOLL regs=%p\n\", $t1; dd $t1+0x2828 L1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; gc" bu i219!I219MiniportSendPackets "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"SEND CNT=%u regs=%p\n\", poi(@esp+0x0c), $t1; dd $t1+0x3810 L1; dd $t1+0x3818 L1; gc" bu ndis!EthFilterDprIndicateReceive ".echo NDIS_RX; gc" bu ndis!EthFilterDprIndicateReceiveComplete ".echo NDIS_RXC; gc" g

@reboot12 I go back to the very first version, just shrink the size of the rings to half and run this KD commands in one block. bc * bu i219!I219MiniportInitialize ".echo INIT; gc" bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"TXRXSTART a=%p regs=%p\\n\", $t0, $t1; dd $t1+0x2808 L1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; dd $t1+0x3808 L1; dd $t1+0x3810 L1; dd $t1+0x3818 L1; gc" bu i219!I219MiniportHandleInterrupt ".echo HINT; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"RXPOLL regs=%p\\n\", $t1; dd $t1+0x2828 L1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; gc" bu i219!I219MiniportSendPackets ".printf \"SEND CNT=%u\\n\", poi(@esp+0x0c); gc" bu ndis!EthFilterDprIndicateReceive ".echo NDIS_RX; gc" bu ndis!EthFilterDprIndicateReceiveComplete ".echo NDIS_RXC; gc" g If it stops, type g again and again Dietmar https://www.upload.ee/files/19112000/i219V1ring16.zip.html

@reboot12 Here is v12. And use this code for KD in one block Dietmar https://www.upload.ee/files/19111897/i219v12.zip.html bc * bu i219!I219RxKick ".echo RXKICK; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"RXPOLL regs=%p\\n\", $t1; dd $t1+0x0100 L1; dd $t1+0x2828 L1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; gc" bu i219!I219MiniportSendPackets ".printf \"SEND CNT=%u\\n\", poi(@esp+0x0c); gc" g

@reboot12 Here is next version 11. Take the same KD commands as before Dietmar https://www.upload.ee/files/19111837/i219v11.zip.html

@reboot12 This board has 2 lan slots i219 and i210. Are you sure, that your cable is in the correct i219 slot Dietmar

no dhcp

@reboot12 ok, here is version v10 and use those windbg KD code Dietmar https://www.upload.ee/files/19111776/i219v10.zip.html bc * bu i219!I219MiniportHandleInterrupt ".echo HINT; gc" bu i219!I219RxKick ".echo RXKICK; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"RXPOLL regs=%p\\n\", $t1; dd $t1+0x280c L1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; gc" bu i219!I219MiniportSendPackets ".printf \"SEND CNT=%u\\n\", poi(@esp+0x0c); gc" g

@reboot12 Here it is, good luck, When it does not work, use those KD commands as before Dietmar https://www.upload.ee/files/19111729/i219v9.zip.html bc * bu i219!I219MiniportInitialize ".echo INIT; gc" bu i219!I219MiniportQueryInformation ".printf \"QRY OID=%08x LEN=%u\\n\", poi(@esp+8), poi(@esp+0x10); gc" bu i219!I219MiniportSetInformation ".printf \"SET OID=%08x LEN=%u\\n\", poi(@esp+8), poi(@esp+0x10); gc" bu i219!I219DoCtrlKickLate ".echo CTRLKICK; gc" bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"TXRXSTART a=%p regs=%p\\n\", $t0, $t1; dd $t1+0x0008 L1; dd $t1+0x00d0 L1; dd $t1+0x0100 L1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; gc" bu i219!I219MiniportSendPackets ".printf \"SEND CNT=%u\\n\", poi(@esp+0x0c); gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"RXPOLL regs=%p\\n\", $t1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; gc" bu i219!I219MiniportISR ".echo ISR; gc" bu i219!I219MiniportHandleInterrupt ".echo HINT; gc" g

@reboot12 I take a look at the Linux Source Code e1000e. Then I send you a new driver v9 Dietmar

@reboot12 Yes, mostly. I noticed, that Windbg sometimes out of nowhere changed the path to C:\symbols to something other. This you see at once, when you kept all those comands Dietmar PS: Now I look at your output. Everything is ok, only RX does not act for to get packages. Now I look for next commands for KD, WHY this happens.