Mesa hm2/hm2_7i96s.0: error finishing read

Odd looking in Synaptic I have linux-image-6.1.0-rt5-liuxcnc-rt installed but don't see any header for 6.1...

JT

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