M4300 stack-port RX discarded packets, high mgmt latency

Hello,

I have 4 M4300-28G-PoE+ (IP 192.168.101.4, fw version 12.0.19.23) in a stack ring, and one M4350-48G4XF (IP 192.168.101.5, fw 14.0.6.9), which is connected to the stack via 4 port LAG, each cord connected to one switch from the stack.

The asic switching seems fine, I have <1ms latency on every device in the network, except for the stack management IP. Counters show RX discards on all but one stack cord (which is logically disconnected to prevent loop). The discards bleed steadily and more heavily if there are more devices in the network, though the data rate shows around 90Mb/s on each stack interface, which is nothing, when the stack interfaces show 10Gbit links. There are no errors, just RX discards (show stack-port counters all) as if the CPU buffer can't handle it. The stack management IP also has higher ping, 1-2ms with up to 80ms peaks. Those peaks are probably correlated with CPU usage spikes, normally sitting around 15 % on the Mgmt Sw, going well over 50% and even up to 80% (with agentMain, tRpcsrv.01000 and syncdb eating up the most at those peaks).

There is VuWall AV system populating most of the switch ports.
I have igmp-plus set up and igmpsnooping, with querier being the switch 192.168.101.4 (snoopTask eats almost nothing). The secondary switch 101.5 has set igmp mrouter 101 on the LAG and querier set to 101.4. Therefore IGMP should be correctly configured.

I tried:
Set all recommended settings for Netgear by VuWall.
Upgraded FW from 12.0.19.21 to 12.0.19.23.
Different presets in switch GUI.
Disconnecting 3 out of 4 LAG ports.

port-channel load-balance 3 and 6 and I have port-channel local-preference on that LAG, on both stack and M4350

I guess discarding rx packets on stack interfaces isn't a feature.
Only the stack interface is having this high latency and sometimes our video streams freeze (this can be totally unrelated to the switch issue though)

Disconnecting almost all devices, problems weren't as severe but persisted, which seems to me more like a broadcast storm/topology problem, rather than low bandwith problem.

Any ideas of what could have been wrong?