Dietmar

@reboot12 When you send me the test results for XP SP3 for i219-LM with the commands for Windbg which I give to you, there is a chance that I can figure out what happens Dietmar

Hi, I just test my last versions of i219 and RTL8125 on the Asrock z690 Extreme board with 12900k cpu. And voila, here they work both. The RTL8125 is a Dragon RTL8125BG chip, while on the Gigabyte z690 UD DDR4 the RTL8125 chip was a version RTL8125A, so this driver seems to be really generic Dietmar

@reboot12 A lot of times I had the same problem with the Symbols for Windbg. But here you wrote the solution from yourself. Windbg is looking for its symbols in c:\symbols\symbols\sys\ so just be kind to Windbg and copy and paste all your symbols to this place also Dietmar

@Damnation Hi, I just look. how Linux, Reactos and FreeBSD build those drivers, look for their Source Code which is online available. And I use ChatGPT for to find online all the values for needed registers. Always I doublecheck this values. Then I start to build a sceleton of a driver, that just installs, without any send or get function. Via this way I can check all the time Bsods, Code 37, 39, 10 with Windbg and solve one by one. I really get much better in using Windbg. For to interpret all the for me unknown output from Windbg, I also use ChatGPT but this Interpretation was correct only in about 50%. 3 years ago I build my own small KI. And via this knowledge I know very good, how you need to ask a Ki for to get a not stupid answer. It happens a lot f times, that forums etc. tell wrong things, so I wonder how they ever can make a working driver from this information. Do you tested a Lan driver (i219 or RTL8125) from me and does it work? Yes, this warning happens to me also. At a place I make another definition of a function, that I define at another place before. The checked version compiles just with this warning, for the free version I have to delete this second definition of the function, as I remember just 15 lines cut Dietmar

@reboot12 I make a new i219v3 for you with new i219.inf and put its i219.pdb also in it. After my experiance with the RTL8125 driver yesterday I come to the idea, that maybe your compi needs just more information durring install from the i219.inf . Uninstall your old i219 in Device Manager. And then "search for new hardware". And point to this new i219.inf . If you get a message, that the device cant be found, click right on this i219.inf and click "install". Then reboot compi, Then point again in Device Manager to the i219. Do not delete this time the i219 there. Just "update driver" and show it to this new i219.inf. I just test this methode on my compi with the same i219-LM as yours, good luck Dietmar https://www.upload.ee/files/19105087/i219LMV3mitneuer_INF.zip.html

Hi, I learned soso painfull, that I have to edit the RTL8125.inf file. But now it is ready. This is by far the best driver, that I ever made, here also with Source Code, please test Dietmar https://www.upload.ee/files/19104527/RTL8125allbest.zip.html

Here is a new version of RTL8125 for XP SP3. I succeed, what even not win10 manages, to let it run on pure legacy IRQs. This makes it fast as much as possible, <1ms ping to DHCP router Dietmar

@reboot12 .logopen /t c:\i219_kd.log .reload /f i219.sys lmv m i219 bc * bu i219!I219MiniportInitialize bu ndis!NdisMMapIoSpace bu i219!I219IndicateMediaState bu i219!I219MiniportQueryInformation bu i219!I219MiniportSetInformation bu i219!I219DetectPhyAddr bu i219!I219MdicRead bu i219!I219MdicWrite bu i219!I219DisableUlpPhy bu i219!I219LowPowerExitFixup bu i219!I219LinkFromStatus bu i219!I219PollTimerFunc bu i219!I219MiniportISR bu i219!I219MiniportHandleInterrupt bu i219!I219MiniportSendPackets bu i219!I219TxSendOne bu i219!I219TxReclaim bu i219!I219RxPoll g kv r dd esp L20 dd esp L20 r $t0=poi(esp+4) gu dd $t0 L1 r $t1=poi($t0) dd $t1+8 L1 kv r dd esp L20 r $t0=poi(esp+4) dt i219!_I219_ADAPTER $t0 LinkState LinkIndicated PacketFilter HasMmio HasPhy InterruptRegistered IrqHits IrqSeen r $t1=((i219!_I219_ADAPTER*)$t0)->Regs dd $t1+8 L1 kv r dd esp L20 dd esp+8 L1 gu r eax !irq dd i219!g_TxSubmits L1 dd i219!g_TxCompletes L1 dd i219!g_TxErrors L1 dd i219!g_RxFrames L1 dd i219!g_RxErrors L1 .logclose It is very difficult to explain each step for me and not to destroy the commands. When you have ChatGPT, you can put the answer from Windbg with copy and paste there and just ask for next steps. ChatGPT does not know all about the Syntax of this Windbg version, so it will be a lot of try and error. Now I am going to restaurant, will be back at about 19:00 Dietmar

@reboot12 Copy and paste and give each in one block to KD: lmv m i219 .reload /f i219.sys x i219!*Miniport* x i219!I219* !drvobj i219 7 then bu i219!I219MiniportInitialize bu i219!I219IndicateMediaState bu i219!I219MiniportQueryInformation bu i219!I219MiniportSetInformation bu i219!I219MiniportISR bu i219!I219MiniportHandleInterrupt bu i219!I219TxSendOne bu i219!I219TxReclaim bu i219!I219RxPoll g send me results Dietmar

Here is version 2 of the driver RTL8125 for XP SP3. May be it works also on Realtek/Killer E3000 2.5GbE and Dragon 2.5GB. This version now counts all packages correct. Please test and tell me results Dietmar

@reboot12 It looks, as if the symbols are not extracted Dietmar

@reboot12 It is crazy from Microsoft to put the correct path to symbols. But it is training, HOW crazy it is to work with Windbg Dietmar

@reboot12 I think, you have now a double folder c:\symbols\symbols change this to c:\symbols Dietmar

@reboot12 This is not an error. It is a breakpoint from XP. From there you have to continue in KD with g Dietmar PS: Make an extra line in boot.ini multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /debug /debugport=com1 /baudrate=115200 /break because then you can always choose, if you want debug or normal XP start.

@reboot12 Tippe in Windbg in KD: .sympath C:\symbols .reload After this type in KD .sympath /v and then !sym noisy .reload /f Dietmar EDIT: For the i219: Make a folder C:\i219 and copy the i219.pdb from v5 into it. Use only this V5 version of i219.sys Type then in KD .sympath+ C:\i219 .reload then in Kd .sympath /v Then at each Windbg setting for testing something with the i219.sys type in KD !sym noisy .reload /f sxe ld:i219 sxe ud:i219 g .reload /f i219.sys lm m i219 This you have to do, because it is not possible in Windbg to add a *.pdb to a driver, that is not already loaded. Oh my, this makes me headache to figure this out Dietmar

@reboot12 You need the full symbol package, because the update version contains only the XP SP3 symbols, that are added for XP SP3 from 2008 until 2014 Dietmar

@reboot12 Do you have the original Symbols for XP SP3, NOT the debug version? WindowsXP-KB936929-SP3-x86-symbols-full-ENU.exe First unpack them to a folder C:\symbols Do not choose another name or other path. Dietmar

@reboot12 Yes, most of the time nothing works. Albert Einstein says one time: "I only start with something, when I see a light at the end of the tunnel." This is not me. I even start to work, when after days I do not see a hint for a small light at the end of the tunnel. This behavior, that you dont see any packages, is, that your DHCP router is not "seen" from your lan card and vice versa. A working ping means to send and to receive, even with no count of packages in XP. When you send me some information via Windbg, together we will solve this problem. I had exact this problem with the i219, when I enlarge the size of the rings. And I have no idea why. So I go down with size of the rings, that this behavior does not happen to me. The i219 is much more crazy in behavior than the RTL8125. But for me it was the ideal training ground Dietmar

Yesssssaaa!!!!!!! after 48 hours crazy work with Windbg I get a lan driver for the 2.5 GB Realtek RTL8125 under XP SP3. I have not tested everything until now, but look at this..nicccceeee Dietmar

@reboot12 You make BIG progress NdisMRegisterInterrupt ... -> 0x00000000 means work now. # ============================================================ # i219 XP IRQ/TX/RX DEBUG SCRIPT for WinDbg (copy/paste all) # ============================================================ # Goal: # - prove what IRQ gets CONNECTED (HalGetInterruptVector / IoConnectInterrupt) # - prove ISR fires repeatedly (not only once) # - detect if interrupts get masked (writes to IMC/IMS) # - prove whether TX and RX paths run # # IMPORTANT: # - This script assumes your BAR0 from log is: c0200000 # - Adjust symbol names if your build uses different function names. # - If any bp fails, run: x i219!*Interrupt* / x i219!*Send* / x i219!*Rx* # and replace the breakpoint target names accordingly. # # Output log file: # C:\i219_friend_irqtrace.txt # ============================================================ .symfix .sympath+ C:\symbols .reload /f .logopen /t C:\i219_friend_irqtrace.txt # If you have local PDBs, add your path (EDIT THIS PATH if needed): # .sympath+ C:\i219_xp_wdk7600_skeleton_v33_register_morehandlers_stubsfix\wdm\objchk_wxp_x86\i386 # .reload /f i219.sys # Stop when i219 loads sxe ld:i219 g # Show module + symbols lm m i219 x i219!* # ------------------------------------------------------------ # Set BAR0 base (from your log) # ------------------------------------------------------------ r @$t0 = 0xC0200000 .printf "BAR0=%p\n", @$t0 dd @$t0 L2 # ------------------------------------------------------------ # 1) See how HAL translates IRQ (bus lvl/vec -> system vector/irql) # ------------------------------------------------------------ # Prints: InterruptType, BusNumber, BusIrql(Level), BusVector bp hal!HalGetInterruptVector ".printf \"HalGetInterruptVector IT=%u Bus=%u L=%u V=%u\\n\", poi(@esp+4), poi(@esp+8), poi(@esp+0xC), poi(@esp+0x10); gu" g # ------------------------------------------------------------ # 2) See what kernel actually connects # ------------------------------------------------------------ # Prints: Vector, Irql, Mode, Share bp nt!IoConnectInterrupt ".printf \"IoConnectInterrupt Vector=%u Irql=%u Mode=%u Share=%u\\n\", poi(@esp+0x14), poi(@esp+0x18), poi(@esp+0x20), poi(@esp+0x24); gu" g # ------------------------------------------------------------ # 3) Find your ISR/DPC/SEND/RX symbol names # ------------------------------------------------------------ .printf "\n--- SYMBOL HINTS (use these to adjust bp names if needed) ---\n" x i219!*HandleInterrupt* x i219!*Isr* x i219!*Dpc* x i219!*Interrupt* x i219!*Send* x i219!*Receive* x i219!*Indicate* x i219!*Rx* .printf "--- END SYMBOL HINTS ---\n\n" # ------------------------------------------------------------ # 4) Count ISR hits + show ICR/IMS/IMC (e1000-style offsets) # ICR=0xC0, IMS=0xD0, IMC=0xD8 # ------------------------------------------------------------ r @$t1 = 0 bp i219!I219MiniportHandleInterrupt "r @$t1=@$t1+1; .if (@$t1<=200) { .printf \"ISR#%u ICR=%08x IMS=%08x IMC=%08x\\n\", @$t1, poi(@$t0+0xC0), poi(@$t0+0xD0), poi(@$t0+0xD8); } ; gc" g # If the breakpoint above fails (symbol not found), # replace i219!I219MiniportHandleInterrupt with whatever your 'x i219!*Interrupt*' shows. # ------------------------------------------------------------ # 5) Trap ANY masking/enabling of interrupts by watching IMC/IMS writes # This is extremely useful if ISR fires once then stops. # ------------------------------------------------------------ ba w4 @$t0+0xD8 ".printf \"WRITE IMC(mask) IMC=%08x EIP=%p\\n\", poi(@$t0+0xD8), @eip; kb; gc" ba w4 @$t0+0xD0 ".printf \"WRITE IMS(enable) IMS=%08x EIP=%p\\n\", poi(@$t0+0xD0), @eip; kb; gc" g # ------------------------------------------------------------ # 6) TX path counter (does NDIS call your send handler?) # ------------------------------------------------------------ r @$t2 = 0 bp i219!I219MiniportSendPackets "r @$t2=@$t2+1; .if (@$t2<=200) { .printf \"TX#%u\\n\", @$t2; } ; gc" g # If symbol differs, replace with your real send handler # from: x i219!*Send* # ------------------------------------------------------------ # 7) RX path counter (do you process/indicate receives?) # ------------------------------------------------------------ r @$t3 = 0 bp i219!I219RxProcess "r @$t3=@$t3+1; .if (@$t3<=200) { .printf \"RXPROC#%u\\n\", @$t3; } ; gc" g # If symbol differs, replace with your real RX worker function # from: x i219!*Rx* or x i219!*Receive* or x i219!*Indicate* # ------------------------------------------------------------ # 8) One-time quick snapshot of key regs after link-up # (run manually when you see LinkState -> UP in your driver log) # ------------------------------------------------------------ .printf "\n--- SNAPSHOT (run after LinkState -> UP) ---\n" dd @$t0+0x0000 L2 dd @$t0+0x0008 L2 dd @$t0+0x00C0 L1 dd @$t0+0x00D0 L1 dd @$t0+0x00D8 L1 .printf "--- END SNAPSHOT ---\n" # ------------------------------------------------------------ # 9) Close logging when done # ------------------------------------------------------------ # .logclose # ============================================================ # How to read results (quick): # - ISR# increases continuously => interrupts fire. # - If ISR# increases but TX# and RXPROC# stay 0 => NDIS not calling send or RX not processed. # - If ISR# hits once then stops and you see WRITE IMC => interrupts got masked; stack shows who. # ============================================================ # NOTE: # Some previously uploaded i219.c/i219.h files on my side may have expired; if you want code patches again, # re-upload the exact current files you are building.

@reboot12 here it is, also with Source files Dietmar https://www.upload.ee/files/19099906/i219-LM-v5.zip.html

@reboot12 I just look at you output from Windbg and will give you soon a new driver i219-LM v5 Dietmar

@reboot12 Do you have Windbg 6.3.9600.17200 X86 ? Then run a Windbg session. Use my i219.pdb . You can load it when you show Windbg the path to it and run !sym noisy .reload /f sxe ld:i219 sxe ud:i219 g .reload /f i219.sys lm m i219 You can ask me or ChatGPT for the output results. At once you will find the reason Dietmar

@reboot12 Yes, there is for sure another problem. I check all my versions for i219. They all work also on the device with Dev_15BB Dietmar PS: I use my last build of acpi.sys. This is the acpi.sys that also Ramsey uses.

@reboot12 I found a compi with exact your Dev_15BB device for i219. And my lan works there (v4) Dietmar