patched AFINETK.SYS: anyone willing to test ?

[Lars]

There are quite a few bug reports in the AN bug tracker regarding AFINETK.SYS crashing with a trap.

I have now taken a stab in the dark and patched AFINETK.SYS (following a suspicion that I have, it's trial and error) and would like to know from anyone having experienced traps in AFINETK.SYS if that improves the situation and reduces or removes any traps you may have with AFINETK.SYS.

Please not that I left AFINET.SYS unmodified but I guess nobody uses this driver any more (and it's superseded by AFINETK.SYS for any kernel that supports KEE which is about any kernel in use by now).

Let me know by private message where to send it to in case you are interested.

Lars

[Martin Iturbide]

Hi

I don't have experienced any trap on this driver yet, but I just want to let the public know what "AFINETK.SYS" is for, just in case. 
Any more input for that EDM/2 page is welcome. I will be willing to try it out on my test VM.

This file is the 32-bit TCP/IP Protocol Drivers using the KEE API introduced with WSeB and Fixpak 13 for Warp 4.

Thanks Lars.

[Lars]

AFINETK.SYS is the TCPIP protocol driver. It interacts with SOCKETSK.SYS which is the sockets driver.
The TCPIP stack is accessed via sockets.

[guzzi]

I have had the occasional trap in afinetk.sys, but they are few and far in between. So few that I'm not sure if testing is useful.

[Dariusz Piatkowski]

Hey Lars,

Sent you a PM.

Yeah, I'd like to take a stab at this. I used to run the MMRE drivers for my RealTek NIC, but once I moved to fibre I discovered that they would trap and the trap always was in the AFINETK.SYS driver. So while the R8169 driver appears to work fine, it is good for only this particular hardware combination I have at the moment.

thanks,
-Dariusz

[Lars]

If you receive a trap in AFINETK.SYS, it will always be helpful to take a screen shot, the more screenshots, the better.
That's because it would be interesting to know if traps happen only at one or two different places in the code or if they happen "all across the board".

For the trap screens I have seen, I can say why the trap technically happens at the point of trap but unfortunately, the root cause is not clear. It seems likely to be an SMP issue. Seems like if you restrict your system to one core that then the traps in AFINETK.SYS go away. At least that is what someone reported to me.

[Dariusz Piatkowski]

Lars!

...Seems like if you restrict your system to one core that then the traps in AFINETK.SYS go away. At least that is what someone reported to me.

OK, I'll test this later tonight, although the TRAPs I did see weren't always immediate, so the full test-cycle might take a few days.

In the meantime, given the above reference and what you documented in the patch itself, what is being changed in the driver:

Code: [Select]

...
replace call to _indcomplete16 with _indcomplete
...

What I'm wondering is as follows: is the patch attempting to serialize the processing and thus potentially avoid any sort of SMP problems from creeping up?

Thanks!

[Lars]

No,unfortunately not.
What the change does:
there is a routine in the protocol driver called "IndicationComplete".
This is called by the MAC driver after it has received and handed over packets to the protocol driver. It's kind of a trigger for the protocol driver to do cleanup (free temporary memory buffers etc.)
The "_indcomplete16" Routine will unblock some blocked thread to resume and do the cleanup while the "_indcomplete" will instead arm a context hook (and subsequently a routine being run on return from the driver (Ring0) to application code (Ring3)). It's just my hope that the second mechanism works better than the first mechanism. But as I said: it's trial and error as obviously,I don't have the AFINETK.SYS source code.
We will see.

[Dariusz Piatkowski]

Lars,

I have patched the driver and re-booted, still using the current version of my NIC driver. Once I have a few days of runtime on this baseline configuration I will move to test the MMRE drivers.

For what it's worth for anyone else attempting to do this, the RPM/YUM install has it's own version of patch.exe in /usr/bin, so when patching this driver make sure you call \os2\patch.exe directly, otherwise you'll get an error message from the patch utility.

Oh, one remark, although it may not be relevant give how long it's been since I actually tested my fibre 1G connection speed: firing up my speedtest python script now shows a noticable steady spike in the CPU core utilization, basically about 50-60% across all CPU cores. I do not recall this being the case in the past, but honestly unless I re-boot with the un-patched AFAINETK.SYS and re-test I cannot confirm. Anyways, I'll get that tested during the next re-boot.

EDIT: Added the screenshot of CPU spikes: two separate tests, show the individual spike groups

[Lars]

I patched yet two other places in the code that might now actually tackle synchronization probs on SMP system, at least, that's my hope.
Sent you a private email.
By the way: since the patch file is cumulative, you will need to restore the original AFINETK.SYS before you rerun patch.exe.
You can also modify fix.pat to your liking and comment out one or the other patch.

[Dariusz Piatkowski]

Hi Lars,

Well, I tried patching the original AFINETK.SYS driver with the udpated fix.pat, however, this is what i get:

Code: [Select]

[G:\mptn\protocol]\os2\patch fix.pat
Patching fix.pat

End of file is at E5C
Enter the hexadecimal offset of patch:

So I'm thinking something is off because the 1st fix did not require this.

I took a look at the fix.pat contents and compared NEW to OLD and there are some differences in the layout, but i'm not sure whether this is related to applying multiple patches or not?

EDIT
====
Hmm...as they say, RTFM everyone...I forgot the "/A" patch.exe command line option...yikes (blushing)!

[Martin Iturbide]

Hi Lars

I applied the second patch that you sent me on my ArcaOS VM. The file size remains the same here.

[C:\mptn\protocol]patch fix.pat /A
Patches applied to AFINETK.SYS

[C:\mptn\protocol]dir afinetk.*

The volume label in drive C is ARCAOS.
The Volume Serial Number is D393:15BF.
Directory of C:\mptn\protocol

 9-13-05  6:30p       318,976      0 a---  afinetk.bak
11-15-20 12:13p       318,976      0 a---  afinetk.sys
        2 file(s)     637,952 bytes used
                   17,629,532 K bytes free

I didn't experiences any trap before, maybe I'm not the best candidate for it, but I just want to tell that nothing broke here for the moment. TCPIP and Internet access keep working fine here.
I guess this is the ticket from AN (0001313).

Regards

[Lars]

Hi Lars

I applied the second patch that you sent me on my ArcaOS VM. The file size remains the same here.

[C:\mptn\protocol]patch fix.pat /A
Patches applied to AFINETK.SYS

[C:\mptn\protocol]dir afinetk.*

The volume label in drive C is ARCAOS.
The Volume Serial Number is D393:15BF.
Directory of C:\mptn\protocol

 9-13-05  6:30p       318,976      0 a---  afinetk.bak
11-15-20 12:13p       318,976      0 a---  afinetk.sys
        2 file(s)     637,952 bytes used
                   17,629,532 K bytes free

I didn't experiences any trap before, maybe I'm not the best candidate for it, but I just want to tell that nothing broke here for the moment. TCPIP and Internet access keep working fine here.
I guess this is the ticket from AN (0001313).

Regards

The nature of a binary patch is that the file size remains exactly the same. Yes, ticket 1313 is one of the tickets. But there are a few others with the same trap in AFINETK.SYS. For example,ticket 1592 even though it errounesly states the EIP=xxxxx352 instead of EIP=xxxxx382 (I don't know why).

[Andi B.]

In ticket #1592 also the Realtek MMRE driver was used. One more indication that the problem is somehow related to this NIC driver.

[Dariusz Piatkowski]

Hi Lars,

OK, a bit of an update, not as crystal clear as I have hoped to report though.

So here is the thing:

1) OLD hardware => MSI 880G-E45 motherboard, NIC was:

Code: [Select]

Vendor 10ECh Realtek Semiconductor Co., Ltd.
 Device 8168h RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

2) NEW hardware => MSI 890FXA-GD70, NIC is:

Code: [Select]

Vendor 10ECh Realtek Semiconductor Co., Ltd.
 Device 8168h RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

By all appearances, the same networking hardware. The motherboard spec sheet also says both are equipped with RealTek 8111DL controller. However, it is different hardware after all since the NIC is in a different motherboard.

So...what did I notice? Well, with the patched AFINETK.SYS and the non-MMRE NIC driver I was fine on the old motherboard (but it was a short test, only about a day or so of usage), basically things seemed like they were working fine. However on the new motherboard I started to see weird non-responsive tcp/ip events. For example, the browser (FF45.9) would just say "...waiting for server to repond..." when attempting to load a page, and yet simply re-loading the very same URL would bring the page up. This happened multiple times, over numerous non-related websites, and across a few re-boots just to rule out a possibility that something else was interfering with the test.

I eventually moved back to the un-patched AFINETK.SYS driver and those events are no longer present. So it feels like something was off...just not sure what to attribute it to?

On the other hand, the MMRE situation is much more clear. When I deployed that NIC driver for my RealTek NIC I ended up with a TRAP in OS2KRNL within 1/2 hr of usage. A few passes of the speedtest worked fine, but on the 3rd attempt it trapped. So that remained consistent on the NEW motherboard hardware with the results I previously saw on the OLD motherboard hardware. The fact that it's still present leads me to conclude that the patches did not address whatever the MMRE driver was having a problem with. Regardless, the patches you produced may never help the MMRE situation to start off with, but it was the only clear symptom that I could watch out for during my testing.

Alright sir, that's all I can report. Happy to test further changes if you want to pursue further Lars!