Mesa hm2/hm2_7i96s.0: error finishing read

No John sorry. Those settings allow building the debs without security keys.
You should be able to use the same method to set the fully preeptible kernel setting which would allow a fully scripted solution to build the kernel

What is solving is it is that by using the pristine kernel.org upstream source, the buggy RT kernel patches applied by Debian are bypassed. I've shared the location of these patches previously. Lazy preemption is my top candidate

I have wondered if you could pull down the RT patch source from debian and use the debian system to rebuild linux-image-rt without some f these patches.

But its good you brought this to the top as I think I've found something useful. See if you can enable CONFIG_NET_RX_BUSY_POLL in the kernel and rebuild it. Then when running that kernel try typing:

sudo sysctl -w net.core.busy_poll=50
sudo sysctl -w net.core.busy_read=50

This enables polling instead of interrupts on the network which results in lower latency at the expense of higher CPU utilisation and prevents the PC to sleep. There are a few references but this one is fairly authoritive
caxapa.ru/thumbs/793343/Open_Source_Kern...cements_for_Low-.pdf
A setting of 50 is recommended by redhat for a few sockets.

PCW, I'm not sure yet if this requires changes to the socket used by hm2_eth to add the SO_BUSY_POLL socket option to the socket.

So the Debian patches are here:
salsa.debian.org/kernel-team/linux/-/tre...er/debian/patches-rt
If you read the file series, it explains whats going on and the orderpatches are applied.
You would need to compare the differences between the buster branch and master branch to find whats changed
But the number of patches in Buster are massive and have slowly been reducing as the real time patches are incorporated into the main line over time. 

I think busy polling requires driver support which does not seem to be present
for common MACs

That said, the stock 6.x kernel seems OK as-is for Intel MACs
(I have about a month of uptime now without any "error finishing read"s)

Does the Driver change fix the Realtek issue?

Peter, this is all conjecture right now as I only just got this far.
I am not sure if the low latency busy_poll/busy_read settings enable low latency for all NIC's or just specific sockets that request it.
Some of the docs always referred to sockets needing to be enabled and that implied the underlying connection (in hm2_eth) to me.
Nowhere does it actually refer to using this on a specific NIC, just sockets.

Damn! The intel doc refers to a specific NIC as a requirement so a dead end

From the debian source, it would be interesting to build the debian RT image without including these patches 

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)