Dietmar

@reboot12 I make a new driver and new KD block, just wait 5 min Dietmar

@reboot12 And this 0: kd> bc * 0: kd> bu i219!I219TxSendOne ".if ((poi(@esp+4)==0) || (poi(@esp+4)<0x80000000)) { gc } .else { r $t0=poi(@esp+4); r $t1=poi(@$t0+0xDC); .if ((@$t1==0) || (@$t1<0x80000000)) { gc } .else { ed @$t1+0x4a80 00000001; ed @$t1+0x3828 0341001f; ed @$t1+0x3840 20000403; ed @$t1+0x3590 00000001; .echo TXFORCE4A80; dd @$t1+0x3590 L1; dd @$t1+0x4a80 L1; dd @$t1+0x5b54 L1; dd @$t1+0x5b58 L1; dd @$t1+0x0008 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc } }" 0: kd> bu i219!I219TxReclaim ".if ((poi(@esp+4)==0) || (poi(@esp+4)<0x80000000)) { gc } .else { r $t0=poi(@esp+4); r $t1=poi(@$t0+0xDC); .if ((@$t1==0) || (@$t1<0x80000000)) { gc } .else { .echo TXAFTER4A80; dd @$t1+0x3590 L1; dd @$t1+0x4a80 L1; dd @$t1+0x0008 L1; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc } }" 0: kd> g

@reboot12 then this !sym quiet .reload /f i219.sys sxd ud bc * r $t9=1 bu i219!I219TxProgramUnit " r $t0=poi(@esp+4); r $t1=poi(@$t0+0xDC); .printf \"TXPROG A=%p R=%p\n\", @$t0, @$t1; .if (@$t9) { r $t2=(poi(@$t1+0x3590)|1); ed @$t1+0x3590 @$t2; .echo FORCE3590; } dd @$t1+0x0008 L1; r $t3=(poi(@$t1+0x0008) & 0x40000000); .printf \"BM_BIT=%08x\n\", @$t3; dd @$t1+0x3590 L4; dd @$t1+0x4a80 L4; dd @$t1+0x5b54 L2; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc " bu i219!I219TxSendOne " r $t0=poi(@esp+4); r $t1=poi(@$t0+0xDC); .printf \"TXONE A=%p R=%p\n\", @$t0, @$t1; dd @$t1+0x0008 L1; r $t3=(poi(@$t1+0x0008) & 0x40000000); .printf \"BM_BIT=%08x\n\", @$t3; dd @$t1+0x3590 L4; dd @$t1+0x4a80 L4; dd @$t1+0x5b54 L2; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc " bu i219!I219TxReclaim " r $t0=poi(@esp+4); r $t1=poi(@$t0+0xDC); .printf \"TXRECL A=%p R=%p\n\", @$t0, @$t1; dd @$t1+0x0008 L1; r $t3=(poi(@$t1+0x0008) & 0x40000000); .printf \"BM_BIT=%08x\n\", @$t3; dd @$t1+0x3590 L4; dd @$t1+0x4a80 L4; dd @$t1+0x5b54 L2; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc " g and this bc * bu i219!I219DoCtrlKickLate "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo CTRLKICK; ? (poi(@$t1+0x0008)&0x40000000); ? (poi(@$t1+0x5b54)&0x01000000); dd @$t1+0x0008 L1; dd @$t1+0x5b00 L1; dd @$t1+0x5b50 L3; dd @$t1+0x3590 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc" bu i219!I219TxProgramUnit "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXPROG; ? (poi(@$t1+0x0008)&0x40000000); ? (poi(@$t1+0x5b54)&0x01000000); dd @$t1+0x0008 L1; dd @$t1+0x5b00 L1; dd @$t1+0x5b50 L3; dd @$t1+0x3590 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc" bu i219!I219TxSendOne "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXONE; ? (poi(@$t1+0x0008)&0x40000000); ? (poi(@$t1+0x5b54)&0x01000000); dd @$t1+0x0008 L1; dd @$t1+0x5b00 L1; dd @$t1+0x5b50 L3; dd @$t1+0x3590 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc" bu i219!I219TxReclaim "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRECLAIM; ? (poi(@$t1+0x0008)&0x40000000); ? (poi(@$t1+0x5b54)&0x01000000); dd @$t1+0x0008 L1; dd @$t1+0x5b00 L1; dd @$t1+0x5b50 L3; dd @$t1+0x3590 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc" g

@reboot12 Next KD block. test during running ping to router and ping to compi each other Dietmar 0: kd> bc * 0: kd> bu i219!I219TxWatchdog "r $t9=poi(@esp); .echo SKIP_TXWD; r eip=@$t9; r esp=@esp+4; gc" 0: kd> bu i219!I219TxSendOne ".if (poi(@esp+4)==0) { gc } .else { r $t0=poi(@esp+4); r $t1=poi(@$t0+0xDC); .if (@$t1==0) { gc } .else { .echo TXONE_NOWD; dd @$t1+0x3590 L1; dd @$t1+0x5b54 L1; dd @$t1+0x5b58 L1; dd @$t1+0x0008 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc } }" 0: kd> bu i219!I219TxReclaim ".if (poi(@esp+4)==0) { gc } .else { r $t0=poi(@esp+4); r $t1=poi(@$t0+0xDC); .if (@$t1==0) { gc } .else { .echo TXRECLAIM_NOWD; dd @$t1+0x3590 L1; dd @$t1+0x5b54 L1; dd @$t1+0x5b58 L1; dd @$t1+0x0008 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc } }" 0: kd> g

@reboot12 Here comes next driver with some funtamental changes and test KD block until desktop via hit "g" good luck Dietmar https://www.upload.ee/files/19121064/i219v51.zip.html bc * bu i219!I219TxReclaim "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXCHK3590; dd @$t1+0x3590 L1; dd @$t1+0x5b54 L1; dd @$t1+0x0008 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc" g and this bc * bu i219!I219TxProgramUnit "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXPROG; dd @$t1+0x3590 L1; dd @$t1+0x5b54 L1; dd @$t1+0x5b58 L1; dd @$t1+0x0008 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc" bu i219!I219TxSendOne "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXONE; dd @$t1+0x3590 L1; dd @$t1+0x5b54 L1; dd @$t1+0x5b58 L1; dd @$t1+0x0008 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc" bu i219!I219TxReclaim "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRECLAIM; dd @$t1+0x3590 L1; dd @$t1+0x5b54 L1; dd @$t1+0x5b58 L1; dd @$t1+0x0008 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc" g and this bc * bu i219!I219TxProgramUnit "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=(poi(@$t1+0x3590)|1); ed @$t1+0x3590 @$t2; .echo FORCE3590; dd @$t1+0x3590 L1; dd @$t1+0x5b54 L1; dd @$t1+0x5b58 L1; dd @$t1+0x0008 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc" bu i219!I219TxSendOne "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXONE; dd @$t1+0x3590 L1; dd @$t1+0x5b54 L1; dd @$t1+0x5b58 L1; dd @$t1+0x0008 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc" bu i219!I219TxReclaim "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRECLAIM; dd @$t1+0x3590 L1; dd @$t1+0x5b54 L1; dd @$t1+0x5b58 L1; dd @$t1+0x0008 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc" g

@reboot12 Next KD block Dietmar bc * bu i219!I219TxReclaim "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXCHK; dd @$t1+0x5b54 L1; dd @$t1+0x5b58 L1; dd @$t1+0x4a80 L1; dd @$t1+0x0008 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc" g

@reboot12 On v50, your colleague already has the same key TX setup as your working machine: IOSFPC = 01011108 TXDCTL = 0341001f TARC0 = 20000403 So the Win10-inspired register pattern itself is in place. So, we need to look for an changing TDH. Use this KD block and type "g" until desktop. You have to start before this KD block compi new, not unplug lan cable Dietmar bc * bu i219!I219TxReclaim "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=(poi(@$t1+0x4a80)|1); ed @$t1+0x4a80 @$t2; .echo FORCE_DMATXCTL; dd @$t1+0x4a80 L1; dd @$t1+0x0008 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc" g

@reboot12 Win10 helps a lot. Now please use this KD block. Because I notice starnge behavior of this driver, means cut connection, you always have to start compi new Dietmar bc * bu i219!I219TxSendOne "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXONE; dd @$t1+0x0008 L1; dd @$t1+0x0f28 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc" bu i219!I219TxReclaim "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRECLAIM; dd @$t1+0x0008 L1; dd @$t1+0x0f28 L1; dd @$t1+0x3410 L5; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc" g

@reboot12 Here is new driver and new KD block with settings special for your Industrial board. Please continue with hitting "g", so that your compi comes to desktop and we can see traffic Dietmar https://www.upload.ee/files/19120778/i219v50.zip.html !sym quiet sxd ud bc * bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRXSTART; dd @$t1+0x0008 L1; dd @$t1+0x0f28 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; gc" bu i219!I219TxReclaim "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRECLAIM; dd @$t1+0x0008 L1; dd @$t1+0x0f28 L1; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; dd @$t1+0x3810 L2; gc" g

@reboot12 Please run this KD block for to check, if I see the difference between your i219-LM for your board and the "normal" version correct Dietmar bc * bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=((poi(@$t1+0x3828)&0xffc1ffdf)|0x0141001f); ed @$t1+0x3828 @$t2; r $t3=(poi(@$t1+0x3840)|0x0f800483); ed @$t1+0x3840 @$t3; .echo WIN10_STYLE_TX; dd @$t1+0x3828 L1; dd @$t1+0x3840 L1; dd @$t1+0x3410 L5; gc" g

@reboot12 Oh..this is very nice! I just found, that this win10 driver for your Industrial board has some extra routines special for your board, that exact matches our problem with TX. Soon I send to you next driver Dietmar

@reboot12 I just come to another crazy idea: Because everything works on your industrial board, only TX not: Please send me your working win10 i219.sys driver and the i219.inf for it. I make a Hex diagnose of this binary just for to fetch the missing path for some registers of your Industrial board, that are not make public until now so Linux cant help here Dietmar

@reboot12 I use the hal.dll for multiprocessors with 4Gb forced from Ramsey. Here is diagnosis for your i219-LM until now: This is the clearest proof so far: Your driver is queuing packets. In your dump, SEND and TXONE fire, and the dword at 0x3818 rises from 0x0 to 0x14, while the dword at 0x3810 stays 0x0. In the e1000e register map, 0x3810 is TDH and 0x3818 is TDT. That means software advances the Tx tail, but hardware never advances the Tx head—so descriptors are being posted, but none are being consumed/completed. That also means the old “DMA/master gate is simply off” theory is mostly ruled out by this snapshot. STATUS=00080603 decodes as FD + Link Up + GIO master enable, and the PCIM_STATE bit (0x40000000) is not set here. So this is not the classic “still stuck in PCIm low-power state” picture. Also, TCTL=0104010a already includes E1000_TCTL_EN and E1000_TCTL_PSP, so the Tx unit is nominally enabled. The most suspicious register in your dump is now TXDCTL=02000000. In current e1000e definitions, the documented TXDCTL fields are threshold bits plus GRAN=0x01000000 and COUNT_DESC=0x00400000, and Linux’s E1000_TXDCTL_DMA_BURST_ENABLE macro builds a very different value from those fields. So 0x02000000 looks nonstandard / likely wrong for this MAC family. That is now my top suspect on the register-programming side. So the narrowed diagnosis is: NDIS send path is alive driver ring bookkeeping is alive tail writes reach the NIC failure is now between posted descriptor and hardware consumption That points to one of these, in order: bad TXDCTL programming bad Tx descriptor format / command bits Tx ring not fully re-armed after link event less likely: a deeper DMA fetch problem despite status looking okay The next best KD block is to watch the Tx FIFO registers (TDFH/TDFT/TDFHS/TDFTS/TDFPC) together with the normal ring registers. If the Tx FIFO stays dead while TDT keeps rising, then the MAC is not even pulling descriptors into its internal FIFO. Those FIFO registers are at 0x3410–0x3430, and TARC is at 0x3840. !sym quiet sxd ud bc * bu i219!I219TxSendOne "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXONE; dd @$t1+0x0008 L1; dd @$t1+0x0400 L2; dd @$t1+0x3410 L5; dd @$t1+0x3800 L0c; dd @$t1+0x3840 L1; gc" bu i219!I219TxReclaim "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRECLAIM; dd @$t1+0x0008 L1; dd @$t1+0x3410 L5; dd @$t1+0x3800 L0c; dd @$t1+0x3840 L1; gc" g

@reboot12 This lan cable disconnect and then connect again I have also. It is an artefakt of this driver, because some settings are too hard, this will be gone in next version. How to use this KD block with the same driver as before: Let it run in Windbg. Then disconnect, connect the lan cable by hand. Then ping the router and compi each other Dietmar PS: I use the hal.dll from Ramsey with the 4GB switch. !sym quiet .reload /f i219.sys sxd ud bc * bu i219!I219MiniportSendPackets ".printf \"SEND CNT=%u ADP=%p\n\", poi(@esp+0x0c), poi(@esp+4); r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"SEND regs=%p\n\", $t1; dd @$t1+0x0008 L1; dd @$t1+0x0400 L2; dd @$t1+0x3800 L0c; gc" bu i219!I219TxSendOne "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXONE; dd @$t1+0x0008 L1; dd @$t1+0x0400 L2; dd @$t1+0x3800 L0c; gc" bu i219!I219TxReclaim "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRECLAIM; dd @$t1+0x0008 L1; dd @$t1+0x0400 L2; dd @$t1+0x3800 L0c; gc" bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRXSTART; dd @$t1+0x0008 L1; dd @$t1+0x0400 L2; dd @$t1+0x3800 L0c; gc" g

@reboot12 Here is new driver and KD Block good luck Dietmar https://www.upload.ee/files/19119931/i219con.zip.html !sym quiet .reload /f i219.sys sxd ud bc * bu i219!I219WaitGoodMacState "r $t0=poi(@esp+4); r $t1=poi(@esp+8); r $t2=poi(@esp+0c); r $t3=poi($t0+0xDC); .printf \"GOODMAC loops=%x needpcim=%x regs=%p\n\", $t1, $t2, $t3; dd @$t3+0x0008 L1; dd @$t3+0x5B50 L3; gc" bu i219!I219TxProgramUnit "r $t0=poi(@esp+4); r $t1=poi(@esp+8); r $t2=poi(@esp+0c); r $t3=poi($t0+0xDC); .printf \"TXPROG_IN deep=%x restore=%x regs=%p\n\", $t1, $t2, $t3; dd @$t3+0x0008 L1; dd @$t3+0x5B50 L3; dd @$t3+0x0400 L1; dd @$t3+0x0410 L1; dd @$t3+0x3800 L3; dd @$t3+0x3810 L1; dd @$t3+0x3818 L1; dd @$t3+0x3828 L1; dd @$t3+0x3820 L1; dd @$t3+0x382C L1; dd @$t3+0x04A80 L1; dd @$t3+0x00C4 L1; r $t4=poi(@esp); bp /1 @$t4 \".echo TXPROG_OUT; dd @$t3+0x0008 L1; dd @$t3+0x5B50 L3; dd @$t3+0x0400 L1; dd @$t3+0x0410 L1; dd @$t3+0x3800 L3; dd @$t3+0x3810 L1; dd @$t3+0x3818 L1; dd @$t3+0x3828 L1; dd @$t3+0x3820 L1; dd @$t3+0x382C L1; dd @$t3+0x04A80 L1; dd @$t3+0x00C4 L1; gc\"; gc" bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRXSTART_IN; dd @$t1+0x0008 L1; dd @$t1+0x5B50 L3; dd @$t1+0x2810 L1; dd @$t1+0x2818 L1; dd @$t1+0x2820 L1; dd @$t1+0x282C L1; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3820 L1; dd @$t1+0x382C L1; dd @$t1+0x00C4 L1; r $t2=poi(@esp); bp /1 @$t2 \".echo TXRXSTART_OUT; dd @$t1+0x0008 L1; dd @$t1+0x5B50 L3; dd @$t1+0x2810 L1; dd @$t1+0x2818 L1; dd @$t1+0x2820 L1; dd @$t1+0x282C L1; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3820 L1; dd @$t1+0x382C L1; dd @$t1+0x00C4 L1; gc\"; gc" bu i219!I219TxSendOne "r $t0=poi(@esp+4); r $t1=poi(@esp+8); r $t2=poi($t0+0xDC); .printf \"TXSEND_IN pkt=%p regs=%p\n\", $t1, $t2; dd @$t2+0x0008 L1; dd @$t2+0x5B50 L3; dd @$t2+0x0400 L1; dd @$t2+0x3810 L1; dd @$t2+0x3818 L1; dd @$t2+0x3828 L1; dd @$t2+0x04A80 L1; r $t3=poi(@esp); bp /1 @$t3 \".echo TXSEND_OUT; dd @$t2+0x0008 L1; dd @$t2+0x5B50 L3; dd @$t2+0x0400 L1; dd @$t2+0x3810 L1; dd @$t2+0x3818 L1; dd @$t2+0x3828 L1; dd @$t2+0x04A80 L1; gc\"; gc" bu i219!I219DoCtrlKickLate "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo CTRLKICK_IN; dd @$t1+0x0000 L1; dd @$t1+0x0008 L1; dd @$t1+0x5B50 L3; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x0400 L1; dd @$t1+0x3828 L1; dd @$t1+0x04A80 L1; r $t2=poi(@esp); bp /1 @$t2 \".echo CTRLKICK_OUT; dd @$t1+0x0000 L1; dd @$t1+0x0008 L1; dd @$t1+0x5B50 L3; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x0400 L1; dd @$t1+0x3828 L1; dd @$t1+0x04A80 L1; gc\"; gc" g

@reboot12 copied away

@reboot12 With the same driver, do this KD block and ping as much as possible to router to compi each other and ipconfig /all ipconfig /renew .. I have to go Dietmar !sym quiet .reload /f i219.sys sxd ud bc * bu i219!I219MiniportSendPackets ".echo SEND; kb; gc" bu i219!I219TxSendOne "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .echo TXONE_IN; .printf \"ctx=%p regs=%p ret=%p\n\", $t0, $t1, $t2; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; bp /1 @$t2 \".echo TXONE_OUT; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; gc\"; gc" bu i219!I219TxReclaim "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRECLAIM; 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); .echo RXPOLL; dd @$t1+0x2810 L1; dd @$t1+0x2818 L1; dd @$t1+0x2828 L1; gc" bu i219!I219MiniportISR ".echo ISR; gc" g

@reboot12 Waaoh, we will bring it to full live soon. But Now I have to go. I am back late in the evening may be 21:00 Dietmar This is the best sign so far. Those three RXPOLL lines mean the RX ring is no longer stuck: RDH (0x2810) moves: 0E -> 12 -> 17 RDT (0x2818) also moves: 09 -> 0E -> 12 That means: the hardware is consuming RX descriptors the driver is reposting them so the RX DMA path is now really alive So the old core failure is gone: DMA is working on RX the NIC is receiving real frames poll/ISR is working TXRECLAIM still at 0/0 in this snippet just means: there is still no proven TX traffic in this exact capture But the very important new fact is: this is not “dead hardware” anymore the board is now seeing inbound traffic on the wire What this means You should not make a new driver yet. A new driver now would be premature, because this latest snippet proves the current driver finally broke through on the receive side. Best next step now Use the current driver and do one focused test: generate real traffic: ipconfig /renew ping router ping another PC directly trace whether TX is actually used: SEND TXONE_IN / TXONE_OUT TXRECLAIM Because now the big missing split is: RX works, but TX never starts vs TX starts too, but upper networking/binding is still the issue New conclusion from this snippet Before: RX was dead (RDH=0 forever) Now: RX is alive descriptors are moving frames are arriving That is a major milestone. So the answer Do not build a new driver yet. Use the current hardwake + keep-poll build. Get the last TX-focused KD log with real traffic. If that next log shows: SEND + TXONE_OUT with moving TDT → then the driver is basically alive and the remaining issue is higher-level networking/binding/config RX moves but no SEND at all → then the next driver (or INF/media-state logic) should focus on binding/media indication SEND happens but no TXONE/TDT movement → then next driver should target the TX submission path

@reboot12 This I get from your log: This is a real improvement. What this log proves now: The new hard-wake path is definitely active: SMBUS hits many times LANPHYPC hits many times PHYSOFTRESET hits twice UNSMBUS happens at the end The keep-poll fix is also working: ISR appears TXRECLAIM appears repeatedly RXPOLL appears repeatedly So two earlier blockers are gone: polling is no longer dying too early the wake code is no longer just “dead code” The strongest good sign: TXRX_OUT shows the rings are now really programmed RX ring base/len/head/tail are set TX ring base/len are set TCTL changes from 3003f0f8 to 0004010a this means I219TxRxStart() is doing real hardware setup now So the driver is much healthier than before. But the core blocker is still here: ANLPAR = 0000 GBSR = 0000 RXPOLL always shows: RDH = 00000000 RDT = 0000001f That means: the PHY/MAC is still not receiving any real frames the RX DMA engine is armed, but the hardware never advances the RX head autoneg with the link partner is still not completing properly Also important: PHY post-ctrlkick ... anar=0de1 gbcr=0200 this is actually good: your new driver is now advertising more modes, including gigabit capability but the partner response is still missing (ANLPAR/GBSR remain zero) So the new driver fixed: wake sequencing poll/IRQ handoff ring programming But it did not yet fix: real partner negotiation actual RX traffic real data path activity on the wire One more important detail: there is no SEND there is no TXONE So in this trace, the OS never really tried to hand a packet to the TX path after the link came up. That means: TXRECLAIM = 0/0 is not yet meaningful we still need a trace with real outgoing traffic My conclusion: This is progress The driver is no longer stuck internally The remaining problem is now mostly link/PHY/partner side, not basic DMA setup

@reboot12 Oh..we make advantages: Ping your router and compi each other during this KD Dietmar !sym quiet bc * bu i219!I219MiniportSendPackets ".echo SEND; gc" bu i219!I219TxSendOne "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .echo TXONE_IN; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; bp /1 @$t2 \".echo TXONE_OUT; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; gc\"; gc" bu i219!I219TxReclaim "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRECLAIM; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo RXPOLL; dd @$t1+0x2810 L1; dd @$t1+0x2818 L1; gc" g

@reboot12 You cant disable ME. The meaning of the LM in the i219LM is, that ME is always allowed. I have only 30 min left for today, I will send you answer to your log Dietmar

@reboot12 The ME is used, for to take not autoriziced drivers from the lan away. Intel and Linux forums tell about, but also they dont have a solution always. I for myself had a crazy fight with it, before my driver works for me. Here is new driver and KD block. May be, we can trick ME Dietmar https://www.upload.ee/files/19117940/i219harder.zip.html !sym quiet .reload /f i219.sys sxd ud bc * x i219!*Wake* x i219!*LowPower* x i219!*Smbus* x i219!*PhySoftReset* x i219!*ToggleLan* bu i219!I219MiniportInitialize "r $t0=poi(@esp+4); .echo INIT; .printf \"ctx=%p\n\", $t0; gc" bu i219!I219ForceSmbusMac "r $t0=poi(@esp+4); r $t1=poi(@esp+8); r $t2=poi($t0+0xDC); .echo SMBUS; .printf \"ctx=%p en=%u regs=%p\n\", $t0, $t1, $t2; dd @$t2+0x0018 L1; gc" bu i219!I219UnforceSmbusMac "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo UNSMBUS; .printf \"ctx=%p regs=%p\n\", $t0, $t1; dd @$t1+0x0018 L1; gc" bu i219!I219ToggleLanPhyPc "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo LANPHYPC; .printf \"ctx=%p regs=%p\n\", $t0, $t1; dd @$t1+0x0000 L1; gc" bu i219!I219PhySoftReset "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .echo PHYSOFTRESET_IN; .printf \"ctx=%p regs=%p ret=%p\n\", $t0, $t1, $t2; dd @$t1+0x0020 L1; bp /1 @$t2 \".echo PHYSOFTRESET_OUT; dd @$t1+0x0020 L1; gc\"; gc" bu i219!I219DetectPhyWithWake "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo DETECTPHY; .printf \"ctx=%p regs=%p\n\", $t0, $t1; dd @$t1+0x0008 L1; dd @$t1+0x0018 L1; dd @$t1+0x0020 L1; gc" bu i219!I219LowPowerExitFixup "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .echo LOWPOWER_IN; .printf \"ctx=%p regs=%p ret=%p\n\", $t0, $t1, $t2; dd @$t1+0x0000 L1; dd @$t1+0x0008 L1; dd @$t1+0x0018 L1; dd @$t1+0x0020 L1; bp /1 @$t2 \".echo LOWPOWER_OUT; dd @$t1+0x0000 L1; dd @$t1+0x0008 L1; dd @$t1+0x0018 L1; dd @$t1+0x0020 L1; gc\"; gc" bu i219!I219MiniportISR ".echo ISR; gc" bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .echo TXRX_IN; .printf \"ctx=%p regs=%p ret=%p\n\", $t0, $t1, $t2; dd @$t1+0x0008 L1; dd @$t1+0x0400 L1; dd @$t1+0x2800 L12; dd @$t1+0x2c00 L1; dd @$t1+0x3800 L12; bp /1 @$t2 \".echo TXRX_OUT; dd @$t1+0x0008 L1; dd @$t1+0x0400 L1; dd @$t1+0x2800 L12; dd @$t1+0x2c00 L1; dd @$t1+0x3800 L12; gc\"; gc" bu i219!I219MiniportSendPackets ".echo SEND; gc" bu i219!I219TxSendOne "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .echo TXONE_IN; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; bp /1 @$t2 \".echo TXONE_OUT; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; gc\"; gc" bu i219!I219TxReclaim "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRECLAIM; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo RXPOLL; dd @$t1+0x2810 L1; dd @$t1+0x2818 L1; gc" g

@reboot12 This log is very revealing. The short conclusion: the wake patch is partially working the PHY is reachable but the NIC is still not fully waking into a stable data state and the missing piece is not the simple DMA/BME force What this log proves: I219LowPowerExitFixup is definitely running It hits twice: once during init once again on PnPEventNotify event=5 I219DetectPhyWithWake is running also twice each cycle I219PhySoftReset is running so the stronger wake path is not dead code I219ForceSmbusMac never hits this is important it means your code never escalates into the SMBus-forced fallback path the reason is likely: normal MDIC/PHY access is already working well enough that the code does not take the “PHY inaccessible” branch That means: the PHY is not completely unreachable the problem is not “MDIC path dead” the problem is more subtle: PHY reachable, but still not negotiating / not staying properly awake The most important register clue: status seen in the breakpoints: 00080643 later 00080640 So only the low link bits are changing transiently. That means: the NIC briefly shows a link-ish state (...43) then falls back again (...40) but the crucial high bit 0x40000000 never appears So the real “good fully-awake state” is still not reached. Another strong clue: anlpar=0000 gbcr=0000 gbsr=0000 This is huge. It means: the PHY can be read but it is not receiving valid partner negotiation data so autoneg with the link partner is not actually completing That fits perfectly with: LinkState -> DOWN 100Mb HD In practice that usually means: fallback/default reporting not a healthy established link the PHY is alive enough to answer registers, but not truly synchronized with the cable partner Also important: MDIC (+0x20) changes: 143f6080 1841796d 184a0000 So PHY transactions are clearly happening. That again confirms: the PHY access path itself is alive therefore the current “wake harder” logic is still too conditional The most useful conclusion Your current wake patch is not failing because it cannot talk to the PHY. It is failing because: it does soft reset it does detect but it does not force the harsher fallback steps unconditionally and the link still does not negotiate with the partner So the next best code change is: force I219ForceSmbusMac(...,1) unconditionally once in the wake path not only when detect fails toggle LANPHYPC unconditionally once during wake not only as a fallback branch then do I219PhySoftReset again keep your new “do not stop polling on first IRQ” change That would convert the wake logic from: “only escalate if PHY seems inaccessible” into: “always do a full brutal wake sequence on this problematic board” That is exactly what this board seems to need. What the log does not suggest not a pure PCI bus-master issue not a dead MMIO BAR not a dead PHY access channel Best interpretation This industrial board’s i219-LM is in a state like: MAC visible PHY readable but PHY power/link state still not fully released So yes: the next move should be a more aggressive unconditional wake sequence, not more “DMA force”. If you want, I can write you the exact drop-in patch block now for: unconditional ForceSmbusMac(1) unconditional LANPHYPC toggle second PhySoftReset then return to normal init

@reboot12 We know for sure the reason, why your i219-LM not send or gets packages. The ME of your Bios just stops it after everything is ready. Here is the next driver, hardened for to force start (wake enable) exact as in Linux Dietmar https://www.upload.ee/files/19117806/i219wakeup.zip.html !sym quiet .reload /f i219.sys bc * x i219!*Wake* x i219!*LowPower* x i219!*Smbus* x i219!*PhySoftReset* bu i219!I219MiniportInitialize "r $t0=poi(@esp+4); .echo INIT; .printf \"ctx=%p\n\", $t0; gc" bu i219!I219DetectPhyWithWake "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo DETECTPHY; .printf \"ctx=%p regs=%p\n\", $t0, $t1; dd @$t1+0x0008 L1; dd @$t1+0x0000 L1; dd @$t1+0x0018 L1; dd @$t1+0x0020 L1; gc" bu i219!I219ForceSmbusMac "r $t0=poi(@esp+4); r $t1=poi(@esp+8); r $t2=poi($t0+0xDC); .echo SMBUS; .printf \"ctx=%p en=%u regs=%p\n\", $t0, $t1, $t2; dd @$t2+0x0018 L1; gc" bu i219!I219PhySoftReset "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo PHYSOFTRESET; .printf \"ctx=%p regs=%p\n\", $t0, $t1; dd @$t1+0x0020 L1; gc" bu i219!I219LowPowerExitFixup "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo LOWPOWEREXIT; .printf \"ctx=%p regs=%p\n\", $t0, $t1; dd @$t1+0x0008 L1; dd @$t1+0x0000 L1; dd @$t1+0x0018 L1; dd @$t1+0x0020 L1; gc" bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRXSTART; .printf \"ctx=%p regs=%p\n\", $t0, $t1; dd @$t1+0x0000 L1; dd @$t1+0x0008 L1; dd @$t1+0x0100 L1; dd @$t1+0x0400 L1; 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); .echo RXPOLL; .printf \"ctx=%p regs=%p\n\", $t0, $t1; dd @$t1+0x0100 L1; dd @$t1+0x2810 L1; dd @$t1+0x2818 L1; gc" bu i219!I219MiniportSendPackets ".echo SEND; gc" g

@user57 @reboot12 I make a new driver for to test my idea about DMA. Here it is and please run the KD in one block Dietmar https://www.upload.ee/files/19117699/i219ForceDMA.zip.html !sym quiet sxd ud bc * bu i219!I219MiniportSendPackets ".echo SENDPKTS; kb; gc" bu i219!I219TxSendOne ".echo TXONE; gc" bu i219!I219TxReclaim "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRECLAIM; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3590 L1; gc" bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRXSTART; dd @$t1+0x2800 L12; dd @$t1+0x2828 L1; dd @$t1+0x2c00 L1; dd @$t1+0x3800 L12; dd @$t1+0x3590 L1; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo RXPOLL; dd @$t1+0x2810 L1; dd @$t1+0x2818 L1; dd @$t1+0x2828 L1; gc" g