The question from lleachii about the neccesity / use case of jumbo frames is quite valid. Anything rare/non-standard functionality can bring up bugs that are not noticed in the normal use.
R7800, which is the older almost identical sister of XR500, is known to have suffered from jumbo frames related problems in its youth due to stmmac driver problems, like also the other ipq806x device with the same chips and drivers. Those problems were supposed to have been fixed with kernel 4.19 (years ago), but it is still quite possible that there can be new issues with that functionality. (Really ancient stuff e.g. https://github.com/openwrt/openwrt/issues/8517 , NBG6817: OpenWrt rebooting constantly)
The maximum usable frame size is defined by the weakest link in the data transfer path, and your specific hardware / software combo may just be triggering an edge case at some driver.
Your comments above:
Those make me to think about something like "Hmmm... Detecting an extra large package, so let's increase buffer size dynamically" failing to detect the "extra 2 bytes for DSA". Evaluating "4096 + 26" instead of "4096 + 26 + 2" ?
Note that these are just random ponderings about the possible corner cases in some drivers, but nothing to really fix your problem...
But you having 1500, 1502, 8190, 8192 as the various MTU sizes sounds error-prone to me.