On the h5, I rebuilt the driver with only 8 buffers in each of the Rx and Tx rings. This makes debug output more concise and may cause things to fail more quickly if they depend in some way on ring size and/or wrap around.
Reducing the ring size had a drastic effect. Now nothing seems to work. Network test 5 (ICMP) and 6 (DNS) both fail, doing nothing. The board does not respond to ping. It does seem to endlessly receive packets, but many are mislabeled as to type (getting labeled as ARP). It looks like contents of the network buffer are getting overwritten.
On the h3, everything just works. Reducing the Tx and Rx ring size to 8 buffers each is just fine -- everything runs as normal.
I see lots of broadcast packets of size 711 -- these come from a windows machine on the network. I thumb my nose in their general direction. These look like IP packets of some sort. We get one every 3 seconds. I use Wireshark to look at these. Indeed they are IP packets and they are UDP. They come from host 54 on my net, which my host file says is the TP-Link AP225 router in my kitchen! Destination port 29810. A search on this port tells me this is the Omada SDN discovery protocol. Well, who would have known, and besides that, who cares?
I see plenty of ARP broadcasts also (of size 60). These are from trona (host 5) asking about host 9 (my esp8266 temperature gadget). It stays powered off most of the time and only wakes up once a minute to capture and transmit data.
It is heartening to see the emac driver work correctly on the H3. I am pleased that I haven't introduced a regression bug. The problems I see affect both Tx and Rx and frankly look like some kind of race condition. I begin to wonder if I have a basic bug in the aarch64 port of Kyu. It is as if locking by disabling interrupts is not working properly or something of the sort.
Tom's electronics pages / tom@mmto.org