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

@user57 The MMIO status gives for sure information, what is going on. For example, after Intel documentation, MMIO mapped status=40080640 this "8" stands for DMA Gio enabled. The 4 in the beginning is always interpreted as "success" while a "0" there tells no success (but not in Intel documents). A Linux person forced in his code of the e1000e this bit to be set, as "4" for "DMA connection" enabled. The question is only, what happens, if I force this bit. The Register on the chip is only "read" but I hacked status with "or" in Hex and tomorrow we will see. Another possibility is, that this "4" shows only, if a connection has success and is 0 for "no sucess". In this case a hack will not work. So question "4" ==> DMA enabled or DMA enabled ==> "4" Dietmar

Intel just lies in their documentation. Here is naked truth: Bit Difference: Bit 30 = 0x40000000 On the i219, bit 30 of the STATUS register is: STATUS.GIO_MASTER_ENABLE_STATUS — indicates whether GIO (PCIe) Master requests are enabled/active. 1 (0x40080640) → GIO Master is active — PCIe bus mastering is enabled and in use 0 (0x00080640) → GIO Master is disabled/idle — PCIe master requests have been quiesced Dietmar

@reboot12 I think, that I found out, what is going on: Was bedeutet das für den i219 Treiber unter XP? Oh..I found something really interesting in both logs. They are nearly identic but NOT in the status of MMIO:works: MMIO mapped phys=df500000 reslen=0x20000 maplen=0x20000 irqL=5 irqV=865 ctrl=00180240 status=40080640not works: MMIO mapped phys=c0300000 reslen=0x20000 maplen=0x20000 irqL=7 irqV=387 ctrl=00180240 status=00080640 Das Web wird durchsucht 27 Ergebnisse Der entscheidende Unterschied zwischen den beiden Logs liegt im Status-Register der MMIO-Mapped-Region (vermutlich das STATUS-Register der e1000e-Familie, Offset 0x8 bzw. ähnlich): Funktioniert: status=40080640 Funktioniert nicht: status=00080640 Der Unterschied ist exakt Bit 30 (vom LSB aus gezählt, also 2³⁰ = 0x40000000): 40080640 = 00080640 | 40000000 Bit 30 ist 1 im funktionierenden Fall Bit 30 ist 0 im nicht funktionierenden Fall Bei Intel-Gigabit-Ethernet-Controllern (e1000/e1000e/i219 usw.) ist Bit 30 im STATUS-Register (meist Register 0008h) typischerweise:Bit 30 = Master Enable / Bus Master Status (oder sehr ähnlich benannt)Es signalisiert, ob der Bus Master DMA vom PCIe-Controller aus erlaubt und aktiv ist. Bit 30 = 1 → Bus Mastering ist enabled → der Controller darf DMA-Transfers initiieren (Rx/Tx-Descriptors, Ring-Buffer-Zugriffe usw.) Bit 30 = 0 → Bus Mastering ist deaktiviert → der Chip kann keine DMA-Operationen starten → der Treiber liest zwar Register, aber es passiert nichts mit Paketen → meist "tot" / kein Link / kein Traffic möglich Was bedeutet das konkret für i219 unter Windows XP?Der i219 (insbesondere ab I219-V/VM usw. ab ~2015/100-Serie-Chipsets) ist offiziell nie für Windows XP supported worden. Intel hat den e1000e-Treiber für XP schon sehr früh eingestellt (letzte offizielle Versionen waren meist für i210/i211/i218, teilweise i219 nur inoffiziell/hackig).Typische Probleme unter XP: Der e1000e.sys-Treiber (oder modifizierte/ältere NDIS5-Version) setzt das Bus Master Enable-Bit im PCIe Command Register (Offset 0x04 im PCIe-Config-Space, Bit 2) nicht oder falsch. XP-PnP/PCI-Enumerator respektiert manche moderne PCIe-Capabilities nicht richtig (z. B. ASPM, Power-Management-States, erweiterte Error-Handling). Auf manchen Mainboards/BIOS-Versionen wird Bus Mastering für den i219-PHY im PCH nicht automatisch freigegeben, wenn der Treiber nicht genau passt. Ergebnis: Der Treiber mapped die BAR, liest CTRL/STATUS, aber Bit 30 bleibt 0 → kein DMA → kein Netzwerkverkehr möglich (auch wenn "Gerät funktioniert irgendwie" angezeigt wird).

@reboot12 Oh..I found something really interesting in both logs. They are nearly identic but NOT in the status of MMIO: works: MMIO mapped phys=df500000 reslen=0x20000 maplen=0x20000 irqL=5 irqV=865 ctrl=00180240 status=40080640 not works: MMIO mapped phys=c0300000 reslen=0x20000 maplen=0x20000 irqL=7 irqV=387 ctrl=00180240 status=00080640 Dietmar

@reboot12 At the moment I compare my output from Windbg with yours. So, it lasts a little bit. Just now you cant do more, wish you a nice day Dietmar

@reboot12 Just now I make a direkt compare with the Windbg output from my i219 board with yours. They are very similar, but mine connects and yours not, so may be we see alittle bit more Dietmar

@reboot12 Next KD Block for the same driver 2.5.3 Dietmar !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

@reboot12 Here is next KD block for the driver 2.5.3 Dietmar !sym quiet sxd ud bc * bu i219!I219TxSendOne "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .printf \"TXONE_IN regs=%p\n\", $t1; bp /1 @$t2 \".echo TXONE_OUT; dd i219!g_TxRx+0x08 L12; dd i219!g_TxRx+0x4C L2; dd poi(i219!g_TxRx+0x08) L4; dd @$t1+0x3800 L3; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3590 L1; gc\"; gc" bu i219!I219TxReclaim "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRECLAIM; dd poi(i219!g_TxRx+0x08) L4; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3590 L1; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo RXPOLL; dd @$t1+0x280c L1; dd @$t1+0x2810 L1; dd @$t1+0x2818 L1; gc" g

@reboot12 Hihi, I am tired also Dietmar

@reboot12 Now your router shows the same 10MB as mine;)).. Here is the next KD block for the 2.5.3 driver, for to understand, what is going on Dietmar !sym quiet sxd ud bc * bu i219!I219MiniportSendPackets ".printf \"SEND CNT=%u\n\", poi(@esp+0x0c); 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; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo RXPOLL; dd @$t1+0x280c 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 new driver version 2.5.3 https://www.upload.ee/files/19115762/i219253.zip.html and block for KD good luck Dietmar !sym quiet sxd ud bc * bu i219!I219IndicateMediaState ".printf \"MEDIA st=%u\n\", poi(@esp+8); gc" bu i219!I219LinkFromStatus "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .printf \"LINKCHK regs=%p\n\", $t1; bp /1 @$t2 \".echo LINKRET; r eax; dd @$t1+0x0008 L1; gc\"; gc" bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .printf \"TXRX_IN regs=%p ret=%p\n\", $t1, $t2; bp /1 @$t2 \".echo TXRX_OUT; dd @$t1+0x0008 L1; dd @$t1+0x0100 L1; dd @$t1+0x280c L1; dd @$t1+0x2810 L1; dd @$t1+0x2818 L1; dd @$t1+0x2828 L1; dd @$t1+0x3000 L1; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3590 L1; gc\"; gc" bu i219!I219MiniportSendPackets ".printf \"SEND CNT=%u\n\", poi(@esp+0x0c); gc" bu i219!I219TxSendOne "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .printf \"TXONE_IN regs=%p\n\", $t1; bp /1 @$t2 \".echo TXONE_OUT; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3590 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+0x3590 L1; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo RXPOLL; dd @$t1+0x280c L1; dd @$t1+0x2810 L1; dd @$t1+0x2818 L1; dd @$t1+0x2828 L1; dd @$t1+0x3000 L1; dd @$t1+0x3590 L1; gc" bu ndis!EthFilterDprIndicateReceive ".echo NDIS_RX; gc" bu ndis!EthFilterDprIndicateReceiveComplete ".echo NDIS_RXC; gc" g

@reboot12 I already try 2 new driver, they all do not connect. Now 3. brrr.. Dietmar

@reboot12 This is really crazy, because everything I did is correct. There must be a hidden switch for this ULP (Ultra Low Power) that killes everything on your i219-LM. Again I do an intensive search with Linux e1000e path, because a lot of different bits are involved in this ULP. And Linux and Intel itself tell the same sleeping symptoms, exact like yours. Soon I send you a ne driver Dietmar

@reboot12 Oh my..crazy repair but now works again and KD code for testing https://www.upload.ee/files/19115474/i219v24.zip.html !sym quiet sxd ud bc * bu i219!I219IndicateMediaState ".printf \"MEDIA st=%u\n\", poi(@esp+8); gc" bu i219!I219LinkFromStatus "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .printf \"LINKCHK regs=%p\n\", $t1; bp /1 @$t2 \".echo LINKRET; r eax; dd @$t1+0x0008 L1; gc\"; gc" bu i219!I219TryBringUp "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"BRINGUP regs=%p now=%u\n\", $t1, poi(@esp+8); dd i219!g_TxRx+0x08 L12; gc" bu i219!I219DoCtrlKickLate "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"CTRLKICK reset=%u regs=%p\n\", (poi(@esp+8)&0xff), $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); r $t2=poi(@esp); .printf \"TXRX_IN regs=%p ret=%p\n\", $t1, $t2; bp /1 @$t2 \".echo TXRX_OUT; dd @$t1+0x0008 L1; dd @$t1+0x0100 L1; dd @$t1+0x0400 L1; dd @$t1+0x2800 L4; dd @$t1+0x3000 L1; dd @$t1+0x3800 L3; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3590 L1; dd i219!g_TxRx+0x08 L12; dd poi(i219!g_TxRx+0x08) L4; dd poi(i219!g_TxRx+0x1C) L4; gc\"; gc" bu i219!I219MiniportSendPackets ".printf \"SEND CNT=%u\n\", poi(@esp+0x0c); gc" bu i219!I219TxSendOne "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .printf \"TXONE_IN regs=%p\n\", $t1; bp /1 @$t2 \".echo TXONE_OUT; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3590 L1; dd poi(i219!g_TxRx+0x08) L4; 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+0x3590 L1; dd poi(i219!g_TxRx+0x08) L4; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo RXPOLL; dd @$t1+0x2800 L4; dd @$t1+0x3000 L1; dd @$t1+0x3590 L1; dd poi(i219!g_TxRx+0x1C) L4; gc" bu ndis!EthFilterDprIndicateReceive ".echo NDIS_RX; gc" bu ndis!EthFilterDprIndicateReceiveComplete ".echo NDIS_RXC; gc" g

@reboot12 Yes, for me is the same, "no network cable connected" Now I look in this mistake in driver. Can last few min Dietmar

@reboot12 Here is total new driver v22 and please use this KD https://www.upload.ee/files/19115299/i219v22.zip.html !sym quiet sxd ud bc * bu i219!I219TryBringUp "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"BRINGUP regs=%p\n\", $t1; dd i219!g_TxRx+0x48 L2; gc" bu i219!I219DoCtrlKickLate "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"CTRLKICK reset=%u regs=%p\n\", (poi(@esp+8)&0xff), $t1; dd @$t1+0x0000 L1; dd @$t1+0x0008 L1; dd @$t1+0x0018 L1; dd @$t1+0x5b50 L1; gc" bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .printf \"TXRX_IN regs=%p ret=%p\n\", $t1, $t2; dd i219!g_TxRx+0x08 L12; dd i219!g_TxRx+0x48 L2; bp /1 @$t2 \".echo TXRX_OUT; dd i219!g_TxRx+0x08 L12; dd i219!g_TxRx+0x48 L2; dd poi(i219!g_TxRx+0x08) L4; dd poi(i219!g_TxRx+0x18) L4; db poi(i219!g_TxRx+0x28) L40; dd @$t1+0x0008 L1; 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+0x3000 L1; dd @$t1+0x3800 L3; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; dd @$t1+0x3590 L1; gc\"; gc" bu i219!I219MiniportISR ".echo ISR; gc" bu i219!I219MiniportHandleInterrupt ".echo HANDLEINT; 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 i219!g_TxRx+0x08 L12; dd i219!g_TxRx+0x48 L2; dd poi(i219!g_TxRx+0x08) L4; dd poi(i219!g_TxRx+0x18) L4; db poi(i219!g_TxRx+0x28) L40; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3590 L1; gc" bu i219!I219TxSendOne "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .printf \"TXONE_IN regs=%p\n\", $t1; bp /1 @$t2 \".echo TXONE_OUT; dd i219!g_TxRx+0x08 L12; dd i219!g_TxRx+0x48 L2; dd poi(i219!g_TxRx+0x08) L4; dd poi(i219!g_TxRx+0x18) L4; db poi(i219!g_TxRx+0x28) L40; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3590 L1; gc\"; gc" bu i219!I219TxReclaim "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .echo TXRECLAIM; dd i219!g_TxRx+0x08 L12; dd i219!g_TxRx+0x48 L2; dd poi(i219!g_TxRx+0x08) L4; dd poi(i219!g_TxRx+0x18) L4; db poi(i219!g_TxRx+0x28) L40; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3590 L1; gc" bu i219!I219RxPoll "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); .printf \"RXPOLL regs=%p\n\", $t1; dd i219!g_TxRx+0x08 L12; dd i219!g_TxRx+0x48 L2; dd poi(i219!g_TxRx+0x08) L4; dd poi(i219!g_TxRx+0x18) L4; db poi(i219!g_TxRx+0x28) L40; dd @$t1+0x2810 L1; dd @$t1+0x2818 L1; dd @$t1+0x2828 L1; dd @$t1+0x3000 L1; gc" bu ndis!EthFilterDprIndicateReceive ".echo NDIS_RX; gc" bu ndis!EthFilterDprIndicateReceiveComplete ".echo NDIS_RXC; gc" g

@reboot12 Make a direct check via KD, if the DMA bit is set Dietmar sxd ud bc * bu i219!I219PciEnsureCmd ".echo PCICMD_CALL; gc" bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .printf \"TXRX_IN regs=%p ret=%p\n\", $t1, $t2; bp /1 @$t2 \".echo TXRX_OUT; dd @$t1+0x0008 L1; dd @$t1+0x0400 L1; dd @$t1+0x2810 L1; dd @$t1+0x2818 L1; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; gc\"; 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 @$t1+0x0008 L1; dd @$t1+0x0400 L1; dd @$t1+0x2810 L1; dd @$t1+0x2818 L1; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; gc\"; 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+0x0400 L1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; dd $t1+0x3810 L1; dd $t1+0x3818 L1; dd $t1+0x3828 L1; gc" bu ndis!EthFilterDprIndicateReceive ".echo NDIS_RX; gc" bu ndis!EthFilterDprIndicateReceiveComplete ".echo NDIS_RXC; gc" g

@reboot12 The driver itself can do 1000MB. But via connection to your router, it is set to 100MB, at me to 10MB. This is normal. Please check again, if in the Bios of your board, that this is set Most likely high-value checks on this board are: AMT / ME / ASF / SOL off ASPM / L1 Substates off Deep Sleep off Network Stack / PXE off Dietmar AIMB-786 BIOS CHECKLIST FOR I219-LM (Dev_15BB) TROUBLESHOOTING IMPORTANT: - Keep LAN1 Controller ENABLED (this is the I219-LM you are testing). - After changing settings, do a FULL POWER OFF, then start again. 1) Advanced -> Network Stack Configuration - Network Stack = Disabled 2) Advanced -> Chipset -> PCH-IO Configuration - LAN1 Controller = Enabled - LAN1 Option ROM = Disabled - LAN2 Option ROM = Disabled - Deep Sleep = Disabled - PCIe Wake = Disabled - Power On by Modem = Disabled 3) Advanced -> Intel ME / AMT / Manageability / PCH-FW - Intel AMT = Disabled - CIRA / Remote Assistance = Disabled - ASF PET Progress = Disabled - ASF WatchDog = Disabled - ASF Sensors Table = Disabled - SOL / Serial-over-LAN = Disabled - MEBx Selection Screen = Disabled 4) Advanced -> PCIe / Power Management - ASPM = Disabled - L1 Substates = Disabled - PCIe Clock Power Management / CLKREQ = Disabled 5) Advanced -> CPU / System Power - C-States = Disabled (test only) - Package C State Limit = Disabled or lowest possible - VT-d / IOMMU = Disabled 6) Advanced -> LAN Power Saving (if present) - EEE / Energy Efficient Ethernet = Disabled - Green Ethernet = Disabled - LAN Power Saving = Disabled - Wake on LAN special power modes = Disabled 7) Boot - Fast Boot = Disabled - PXE Boot / UEFI PXE = Disabled - UEFI Network Boot = Disabled 8) General test rule - Leave only the NIC under test enabled, if BIOS allows it - Use a known-good cable - Test with a simple switch / direct link after BIOS changes

@reboot12 May be, that the bit for DMA is not set. Here comes new driver and KD code for to check this Dietmar https://www.upload.ee/files/19115130/i219v1n.zip.html sxd ud bc * bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .printf \"TXRX_IN regs=%p ret=%p\n\", $t1, $t2; bp /1 @$t2 \".echo TXRX_OUT; dd @$t1+0x0008 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!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+0x0400 L1; dd $t1+0x2810 L1; dd $t1+0x2818 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+0x0400 L1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; dd $t1+0x2828 L1; dd $t1+0x3810 L1; dd $t1+0x3818 L1; dd $t1+0x3828 L1; 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/19115066/i219v1m.zip.html sxd ud bc * bu i219!I219TxRxStart "r $t0=poi(@esp+4); r $t1=poi($t0+0xDC); r $t2=poi(@esp); .printf \"TXRX_IN regs=%p ret=%p\n\", $t1, $t2; bp /1 @$t2 \".echo TXRX_OUT; dd @$t1+0x0008 L1; dd @$t1+0x2800 L4; dd @$t1+0x2810 L1; dd @$t1+0x2818 L1; dd @$t1+0x2828 L1; dd @$t1+0x3000 L1; dd @$t1+0x3590 L1; dd @$t1+0x3800 L3; dd @$t1+0x3810 L1; dd @$t1+0x3818 L1; dd @$t1+0x3828 L1; gc\"; 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+0x3000 L1; dd $t1+0x3590 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); .printf \"RXPOLL regs=%p\n\", $t1; dd $t1+0x0008 L1; dd $t1+0x280c L1; dd $t1+0x3000 L1; dd $t1+0x2810 L1; dd $t1+0x2818 L1; dd $t1+0x2828 L1; dd $t1+0x3590 L1; 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 send you a new driver in 5 min. Use also the new KD Block Dietmar