user57 Posted February 27 Posted February 27 i do not know about this but status codes are not always bit´s often they are like error codes in this case the entire piece is compared - not just 1 bit of it
Dietmar Posted February 27 Posted February 27 @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
Dietmar Posted February 28 Posted February 28 (edited) @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 Edited February 28 by Dietmar
reboot12 Posted February 28 Posted February 28 @Dietmar i219ForceDMA - https://pastebin.com/cjLmTE9L Using pciutils tools I compare PCI Configuration Space i219 card in WinXP 32-bit and WinPE 10 64-bit - BusMaster is Enabled only other IRQ:
reboot12 Posted February 28 Posted February 28 (edited) @Dietmar I cannot disable and/or uninstall your i219 driver if the system has been running for some time. To do this, I need to disable/uninstall the driver immediately after starting WinXP - same noticed on other your drivers - not only ForceDMA Edited February 28 by reboot12
Dietmar Posted February 28 Posted February 28 (edited) @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 Edited February 28 by Dietmar
Dietmar Posted February 28 Posted February 28 @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 Posted February 28 Posted February 28 (edited) @Dietmar I use this industrial motherboard every day with WinXP 64-bit and have no problems - your acpi.sys mod, USB3, NVMe and AHCI - I use in Legacy mode but UEFI also works. I don't understand any of this - the i219 card works without any problems in WinPE (Win10) regardless of what settings I have in the BIOS Edited February 28 by reboot12
Dietmar Posted February 28 Posted February 28 @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 Posted February 28 Posted February 28 @Dietmar i219harder - https://pastebin.com/0H27rk3D 25 minutes ago, Dietmar said: The ME is used, for to take not autoriziced drivers from the lan away. But ME and AMT is Disabled in BIOS
Dietmar Posted February 28 Posted February 28 @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
Dietmar Posted February 28 Posted February 28 (edited) @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 Edited February 28 by Dietmar
Dietmar Posted February 28 Posted February 28 @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 Posted February 28 Posted February 28 26 minutes ago, Dietmar said: Ping your router and compi each other during this KD ping from WinXP to router - Request timed out, 0/0 packet, in WinDbg nothing ping from router to WinXP - Request timed out, in WinXP 0/0 packet but in WinDbg this messages: ISR TXRECLAIM b9788810 00000000 b9788818 00000000 RXPOLL b9787810 0000000e b9787818 00000009 ISR TXRECLAIM b9788810 00000000 b9788818 00000000 RXPOLL b9787810 00000012 b9787818 0000000e ISR TXRECLAIM b9788810 00000000 b9788818 00000000 RXPOLL b9787810 00000017 b9787818 00000012
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now