RTL838x: Netgear GS108T v3 - Ring contention

Hi,
A switch (Netgear GS108T v3, 21.01.1) shows warnings in the log and drops packets aimed towards the device. Traffic entering a port and leaving another port is unaffected/fine:

Tue Nov  9 17:29:43 2021 kern.warn kernel: [88189.851532] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a700003c, cur a700004c
Tue Nov  9 17:29:43 2021 kern.warn kernel: [88189.866290] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a7000040, cur a700004c
Tue Nov  9 17:29:43 2021 kern.warn kernel: [88189.889970] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a7000044, cur a700004c
Tue Nov  9 17:29:43 2021 kern.warn kernel: [88189.969803] rtl838x-eth bb00a300.ethernet eth0: Ring 
...
Tue Nov  9 17:30:28 2021 kern.info kernel: [88234.247018] RX buffer overrun: status 101, mask: ffeff
Tue Nov  9 17:30:28 2021 kern.info kernel: [88234.252886] RX buffer overrun: status 1, mask: ffeff
Tue Nov  9 17:30:28 2021 kern.info kernel: [88234.258510] RX buffer overrun: status 1, mask: ffeff

The error just occurs after a while:

The issue can be triggered by running iperf3:

iperf3 -c 192.168.xx.254 -t0
Connecting to host 192.168.xx.254, port 5201
[  5] local 192.168.xx.13 port 44924 connected to 192.168.xx.254 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  4.69 MBytes  39.2 Mbits/sec    0    233 KBytes       
[  5]   1.00-2.05   sec  2.75 MBytes  22.1 Mbits/sec    0    369 KBytes       
[  5]   2.05-3.26   sec  3.57 MBytes  24.7 Mbits/sec    0    533 KBytes       
[  5]   3.26-4.03   sec  1.12 MBytes  12.3 Mbits/sec    1    551 KBytes       
[  5]   4.03-5.00   sec  0.00 Bytes  0.00 bits/sec    1    551 KBytes       
[  5]   5.00-6.00   sec  1.11 MBytes  9.34 Mbits/sec    0    420 KBytes       
[  5]   6.00-7.00   sec  1.37 MBytes  11.5 Mbits/sec    0    451 KBytes       
...
[  5]  99.00-100.00 sec  0.00 Bytes  0.00 bits/sec    0   1.72 MBytes       
[  5] 100.00-101.00 sec  0.00 Bytes  0.00 bits/sec    0   1.72 MBytes       
^C[  5] 101.00-101.93 sec  0.00 Bytes  0.00 bits/sec    0   1.72 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-101.93 sec  66.2 MBytes  5.45 Mbits/sec    6             sender
[  5]   0.00-101.93 sec  0.00 Bytes  0.00 bits/sec                  receiver
iperf3: interrupt - the client has terminated

On a separate console the log shows this while iperf3 is active:

Tue Nov  9 17:49:50 2021 kern.info kernel: [  903.051213] RX buffer overrun: status 101, mask: ffeff
Tue Nov  9 17:49:50 2021 kern.info kernel: [  903.057182] RX buffer overrun: status 101, mask: ffeff
Tue Nov  9 17:49:50 2021 kern.info kernel: [  903.063026] RX buffer overrun: status 1, mask: ffeff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  903.937196] RX buffer overrun: status 101, mask: ffcff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  903.943113] RX buffer overrun: status 1, mask: ffcff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  903.948754] RX buffer overrun: status 1, mask: ffcff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  903.954392] RX buffer overrun: status 101, mask: ffcff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  903.960362] RX buffer overrun: status 101, mask: ffcff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  903.966204] RX buffer overrun: status 1, mask: ffcff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  904.056387] RX buffer overrun: status 101, mask: ffeff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  904.062297] RX buffer overrun: status 1, mask: ffeff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  904.067934] RX buffer overrun: status 1, mask: ffeff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  904.073570] RX buffer overrun: status 101, mask: ffeff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  904.079537] RX buffer overrun: status 101, mask: ffeff
Tue Nov  9 17:49:51 2021 kern.info kernel: [  904.085384] RX buffer overrun: status 1, mask: ffeff

After terminating iperf3 the message changes and it remains as follows even though the high load situation is now gone:

Tue Nov  9 17:49:59 2021 kern.warn kernel: [  911.986238] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000c4, cur a70000c8
Tue Nov  9 17:49:59 2021 kern.warn kernel: [  911.996379] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000c4, cur a70000c8
Tue Nov  9 17:50:00 2021 kern.warn kernel: [  913.020755] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000cc, cur a70000d8
Tue Nov  9 17:50:00 2021 kern.warn kernel: [  913.030895] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000cc, cur a70000d8
Tue Nov  9 17:50:00 2021 kern.warn kernel: [  913.242054] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000d0, cur a70000d8
Tue Nov  9 17:50:00 2021 kern.warn kernel: [  913.258000] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000d4, cur a70000d8
Tue Nov  9 17:50:01 2021 kern.warn kernel: [  914.217759] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000e8, cur a70000ec
Tue Nov  9 17:50:01 2021 kern.warn kernel: [  914.227900] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000e8, cur a70000ec
Tue Nov  9 17:50:50 2021 kern.warn kernel: [  963.623829] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000c4, cur a70000c8
Tue Nov  9 17:50:50 2021 kern.warn kernel: [  963.633968] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000c4, cur a70000c8
Tue Nov  9 17:50:50 2021 kern.warn kernel: [  963.830442] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000cc, cur a70000d8
Tue Nov  9 17:50:50 2021 kern.warn kernel: [  963.840583] rtl838x-eth bb00a300.ethernet eth0: Ring contention: r: 0, last a70000cc, cur a70000d8

Traffic passing the switch from one port to another is not affected, it seems to pause traffic to eth0 for brief moments. To observe that a ping -A 192.168.xx.254 can be used.

Is this a known issue? I do not mind that the device is easily overwhelmed, I am just surprised that the device enters a state where it is loosing packets even if high traffic stops and remains in this poor state.