Mesa hm2/hm2_7i96s.0: error finishing read

I got an Intel PCIe NIC in a pc running for a week now and I did get one error finishing read but that might have been the PC getting a power blink during an winter weather event.

www.amazon.com/dp/B001CY0P7G

JT

I also try to upgrade my system and had some trouble with this latency. The best result I got with following configuration. Any Idea how to get better. The latency on my old 4.19. kernel was less the half. But at the moment still no error anymore.

lsb_release -d
Description:    Debian GNU/Linux bookworm/sid

uname -a
Linux cnc 6.1.0-3-rt-amd64 #1 SMP PREEMPT_RT Debian 6.1.8-1 (2023-01-29) x86_64 GNU/Linux

cat /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet idle=poll isolcpus=2,3"

halcmd show param hm2*tmax
Owner   Type  Dir         Value  Name
    36  s32   RW        1207088  hm2_7i76e.0.read.tmax
    36  s32   RW         376428  hm2_7i76e.0.write.tmax
    30  s32   RW        1440491  servo-thread.tmax

lspci |grep Ethernet
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (5) I219-LM
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)

system info in file
sudo lshw -short > lshw.txt
 

I would stop there if the problem is gone away. Be sure to use your intel card to talk to mesa.

As an aside, I went to an Ethercat seminar held in Australia on Friday. Beckhoff said they use intel NIC's exclusively  in their devices.
It was interesting to apply the differences between ethercat and other fieldbus systems to our own problem as ethercat is muc more efficient.

I've been pondering if the hm2eth driver and mesa card could use a custom protocol (eg no ip addresses) to avoid the overhead from the layered  TCP transport mechanism. But I'm not the one to do that!
Conceptually, this does not seem hard to do as its normal to only have one mesa card on the etheret connection so let it be a slave and hm2 be the master.

I can't see this problem will go away in later kernels.

I expect the problem to improve as there has a considerable improvement with 6.1/6.2
kernels over 5X. Whether Realtek will fix their drivers is another issue. Intel seem more interested in real time.

Note that TCP is not used by hm2_eth (nor are IP addresses after the host determines
the target MAC address)

I don't think it's so much realteks issue but more Debian's implementation of the RT drivers as they seem to roll multiple drivers from the realtek website into a single driver. By itself installing a Debian version with 6.x as it's default kernel is not the solution until you revert to the kernel.org sources and bypass Debian's patches.

Having hm2 sense a slave without an IP address would reduce support overhead given so many today have no idea about TCP networks.
 

Hello,
I got the same error message when, searched and landed here.
However, and that's my tip: it could also be an electromagnetic intolerance. The error occurs for me when I switch off my suction (SSR relay), I pull the plug and switch off, nothing happens.

I hope Google has translated this usefully, my English is probably worse.

Greeting Frank