Mesa 7i95

Its a bit of a pain to change back and forth because of 2.8 vs 2.9
need Python2.7 or 3.x respectively

Fix for master pushed, not sure how long it will take the buildbot to get up-to-date

ok thanks I will give it a try tomorrow it is getting late here anyway.
thank you I will report back.

Well did quick test and it almost works like a charm. Duty drifts with frequency about +-10% in that 0-100KHz. I did not have lot of time today to test it any further but I am guessing that it might be good enough.
But now having issues starting linuxcnc. It used to come up with this message once in a while but now it takes about 5 to 10 tries to get it started.
Have I screwed anything up in the update process?
here is the linuxcnc.report file:
 

Hmm duty cycle should always be exactly 30% because of the 3 on 7 off table data
(if the frequency does no change per cycle)

The error looks like a communication error. Not sure what would have changed
to cause this, you might ping the card to see if the ping times are reasonable.

I will have to try it bit in depth, It was just a quick sweep today it could have been it. I would not loose sleep on it yet.
Is there any manual page for the table? How does it work exactly?

here is the ping:
PING 192.168.1.121 (192.168.1.121) 56(84) bytes of data.
64 bytes from 192.168.1.121: icmp_seq=1 ttl=64 time=0.747 ms
64 bytes from 192.168.1.121: icmp_seq=2 ttl=64 time=0.341 ms
64 bytes from 192.168.1.121: icmp_seq=3 ttl=64 time=0.361 ms
64 bytes from 192.168.1.121: icmp_seq=4 ttl=64 time=0.341 ms
64 bytes from 192.168.1.121: icmp_seq=5 ttl=64 time=0.332 ms
64 bytes from 192.168.1.121: icmp_seq=6 ttl=64 time=0.340 ms
64 bytes from 192.168.1.121: icmp_seq=7 ttl=64 time=0.339 ms
64 bytes from 192.168.1.121: icmp_seq=8 ttl=64 time=0.355 ms
64 bytes from 192.168.1.121: icmp_seq=9 ttl=64 time=0.244 ms
64 bytes from 192.168.1.121: icmp_seq=10 ttl=64 time=0.357 ms
64 bytes from 192.168.1.121: icmp_seq=11 ttl=64 time=0.187 ms
64 bytes from 192.168.1.121: icmp_seq=12 ttl=64 time=0.253 ms
64 bytes from 192.168.1.121: icmp_seq=13 ttl=64 time=0.207 ms
64 bytes from 192.168.1.121: icmp_seq=14 ttl=64 time=0.344 ms
64 bytes from 192.168.1.121: icmp_seq=15 ttl=64 time=0.271 ms
64 bytes from 192.168.1.121: icmp_seq=16 ttl=64 time=0.318 ms
64 bytes from 192.168.1.121: icmp_seq=17 ttl=64 time=0.235 ms
^C
--- 192.168.1.121 ping statistics ---
17 packets transmitted, 17 received, 0% packet loss, time 408ms
rtt min/avg/max/mdev = 0.187/0.327/0.747/0.120 ms

Look like possibly you have a Intel MAC and have not disabled IRQ coalescing
(this is described in the hm2-eth manual page)

it looked like that helped. It behaved nicely for few tries but now it throws the same error again.

What are your ping times now?

Also it looks like master was broken briefly yesterday so re-fetching may help

times are almost half what they were first time
I will try to refetch and report back

Did the re-fetch and it just got worse. Now it wont load at all.
First problem was simple to solve even for my little brain and after refetch IPTABLES got root permissions for some reason, I have changed it and the result is in attached report.