error finishing read

The linux kernel is the same accross linux versions (and platforms)
ref: git.kernel.org/

We found the linux master is now at 6.3 rc6 and is not yet downloadable. YOU need to use git


It might be better to wait until 6.3 is released...

With some help from Joco-nz, I was able to build the 6.3 kernelwhich are available for download here
drive.google.com/drive/folders/1f3Gk1qDE...7IJ3Ws98?usp=sharing
I recommend you install using sudo depackage -i
Note there is a document in the folder that lists the steps required.
The difference from other kernels we've built is that 6.3 has not been released so we pull the source from git.

See how you go. It seemed odd here becaue isolcpus=2,3 had higher latency than without, yet it did not suffer from error finishing read.
Ooops I just remembered I have not installed the RT8168 driver yet!

Had a setback. The R8168 driver is not availal ein the repos for the 6.3 kernel. I tried to install from source from the realtek website and it removed the existing R8169 driver and left me with no network and no way to restore it. 

I rebooted into the original 6.1 kernel and the network was there so I think I just need to uninstall the 6.3 kernel andstart again.

I am going to assume that the R8169 driver has now been fixed for the R8168/R8111 as ping times seem to have substantially improved..(even in the 6.1 kernel)

I was able to build rc6 version
You could test from here.
drive.google.com/drive/folders/1HceAcPQd...u4zS9?usp=share_link

​​​​​​​For my Pc is not really different latency time to your rc5 version. I note the time is a little less and more stable, but I use an intel 82576 gigabit network card. I note the r8168-dkms is available for your realtek card. You should be able to build a quick driver from there.

Second i use "make olddefconfig" again and check the different between your and my config. Not sure but for me, i not see that "olddefconfig" is a bad idea but quite simple and compile never fails with this option. I write it down in diff.txt file

However this boot options give in my case best result isolcpus=2,3 ht=on
time now here
 

PCW wrote:

I have just tested the 6.3-rc5-rt7 kernel and it has improved Ethernet latency
At least on my test machines, it seems as good as 4.19
 

I can confirm this. Latency from 6.1-7 kernel currently shipping with the latest Debian 12 (Bookworm) has improved by 265% with the custom built 6.3.0-RC5-8 kernel from pristine sources. Error Finishing Read seems to be eliminated
on this Resltrk R8111 NIC which has always proved problematic. This is still with the default R8169 driver as I was unable to install the R8168-dkms driver on the custom kernel. I m hoping Debian have added improvements to the default driver.
 
A short test but I've previously done tests overnight with youtube.

Update: The r8168-dkms driver can be de downloaded as a deb file from the Debian sid repositories here:
ftp.de.debian.org/debian/pool/non-free/r...s_8.051.02-2_all.deb
it can be installed by typing:For more information about whether you require this driver, refer this sticky post
forum.linuxcnc.org/9-installing-linuxcnc...dware-eg-realtek-nic
 

PCW wrote:

I have just tested the 6.3-rc5-rt7 kernel and it has improved Ethernet latency
on at least 2 of my test systems: ~4 days LinuxCNC running with YouTube videos
and no more that ~300 usec read tmax and 0 dropped packets at a 1KHz servo thread.

At least on my test machines, it seems as good as 4.19

I reported this isse to the Linux RT team and have received an initial response. ONe thing they said was:

Okay. Then it could be related to softirq rework which started in
v5.0.19-rt11 and updated in v5.9-rc6-rt9.

Early days yet but they have talked about doing a trace and stopping it when the EFR happens. I wondered if the hm2-eth driver can be modified could be modified to stop the trace when an EFR (shorthand  jargon for Error Finishong Read) happens... 

If you have tracing enabled you would want to stop it on a packet error,
not EFR. This is available hal pin so you could launch a script
to stop the trace when it becomes true (or the packet error total is > 0)

PCW wrote:

If you have tracing enabled you would want to stop it on a packet error,
not EFR. This is available hal pin so you could launch a script
to stop the trace when it becomes true (or the packet error total is > 0)

Great Peter, 
So a custom component could read those pins and stop the trace in real time. Very cool. That will make it pretty easy.

A final version of RT has been released for Linux kernel V 6.1. They say

Or to build 6.1.26-rt8 directly, the following patches should be applied:

   www.kernel.org/pub/linux/kernel/v6.x/linux-6.1.tar.xz

   www.kernel.org/pub/linux/kernel/v6.x/patch-6.1.26.xz

   www.kernel.org/pub/linux/kernel/projects...-6.1.26-rt8.patch.xz
 

eg patch the kernel to get to 6.1.26, then proceed as normal with RT patches. Given that Debian Bookworm release is imminent, it might be worth trying this out as it will use kernel 6.1 

I'm currently building the 6.3 Debs again but I see now I should have patched the kernel before applying the RT patches.
Note to self: Be sure to set the flags to disable debug. It's still going in the morning!