error finishing read

to find the CPU in use  by your NIC now
use ip a to determine your NIC name. say eth0

then type: cat /proc/interrupts 
to list all your interrupts
look for eth0 and note the CPU that is > 0
That's the CPU core your NIC is using
I've often wondered where you have 2 cores isolated (eg isolcpus 2,3) if it would be better to Linuxcnc on a different core to the NIC or it's better to be on the same as Linuxcnc  but have never tested. 
​​

PCW wrote:

Python is not needed, a simple bash script should do.

Something like:
#bash
stat=0
while (($stat < 1))
do
  stat=`halcmd getp hm2_7i96s.0.packet-error-total`
done
trace-cmd stop

So I was having a read of the hm2-eth documentation about all of the error pins.  I think we chould change the value for stat to be a higher limit say packet-error-limit - 1

The current script means that there is only one intance of the error when kernel tracing. I think a few more  erorrs in the trace log will help

You could poll hm2_7i96s.0.packet-error which is set true on every error
(and cleared on the next succesful cycle)
or change the script to detect changes in packet-error-total

Will the IRQ for your NIC never change?

Probably not unless you add or change hardware.
Best network latency is helped by pinning the RT Ethernet
IRQ to the isolated CPU used for LinuxCNC

Ideally this would be done by a script

Anyone have any ideas on this? Failure only happens on the hour and then days or weeks apart. Look at the time and date on failure.

And the machine is normally not running.

What Ethernet card do you have? Follow these steps to find out
linuxcnc.org/docs/2.9/html/getting-start...ltek_network_drivers
And read it all if it's a Realtek

If it's an Intel NIC, be sure to add the coalescing settings as per: man hm2_eth

In addition to what rodw said about disabling IRQ coalescing:

1. Are you using the 10.10.10.10 address? (you should)
2. On that hardware make sure you disable AMT in the BIOS.

(Don't want Intels management engine doing random accesses
to the Ethernet hardware)

I have more than 1 month  uptime on identical hardware with not only no
"error finishing read"s but 0 timed out packets.

(You need 5 timed out packets in a row to trigger an "error finishing read"
error with default settings)