por:

Curious detail: the ipq806x-gmac-dwmac refer to faults with eth0, but these fault do occur only when the switch is connected to eth1 ...

please IGNORE

por:

This OOPS also happens on a tplink-c2600, so it concerns more devices of the ipq806x target.

Also on the c2600 the OOPS is preceded by a number of messages like
kern.err kernel: [ 92.235675] ipq806x-gmac-dwmac 37200000.ethernet eth0: len 1994 larger than size (1536)

The error happens within a minute after WAN is connected to the modem.

A test where WAN was mapped to a port on eth1 also resulted in the OOPS.

This OOPS is triggered when WAN is connected to a UBEE cable modem - presumably that device outputs frames with an incorrect len. Within a few days the ISP will change the modem for another DOCSIS3 modem. (A test behind a Compal modem did not trigger the OOPS).

por:

According to the OpenWrt forum the error also hits the NBG6817.

por:

In drivers/net/ethernet/stmicro/stmmac/stmmac_main.c, when length of received frame is larger then the size of the DMA buffer, the message mentioned above is logged and the code breaks from the loop processing arrived frames. [1].

This break was introduced in a commit named "stmmac: fix oversized frame reception" (commit 527c4a769d375ac0472450c52bde29087f49cd9) [2].

Speculation 1:
Some of the other conditions are followed by an else branch within the loop in stead of a break out of the loop, so maybe breaking out is not a correct step.
Since the OOPS is always preceded by several occurrences of oversized frames, possibly some needed resource handling (DMA ?) is skipped.

Aside, in the code directly following the test on the frame length follows a test (LLC frame type) that subtracts a few bytes from the length. Could it be that this test should be above the test on the frame length ?

Speculation 2:
Possibly the frame length is not correctly determined.

[1] https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#L3398

[2] torvalds/linux@e527c4a

hnyman:

Just adding here the best analysis & possible fixes that I have seen so far:

discussion by "ewald" in forum:

https://forum.openwrt.org/t/nbg6817-openwrt-rebooting-constantly/23036/51

(and a few earlier messages in the same thread)

I have been trying to fix the stmmac_main.c by adding code to properly deal with this unexpected larger size packages, but it requires a lot of code changes due to the way the rx ring buffer sizes are (pre)allocated based on MTU size.
The kernel panic that I hit was due to a missing call to set the proper dma size (basically dma would overrun the buffer based on the real size of the packet) size after which an skb buffer free would free illegal memory. There is now a patch for this problem: here 2. I managed to fix this and 2 other issues, but kept hitting new bugs like starvation (basically ethernet port hangs).
I believe the correct fix for this is now posted here 2. Most hangs went away, but some remained...
When you configure a larger MTU, the driver allocates a 2K, 4K or 16K buffer and in this way manages to bypass a number of defects due to the extra headroom.
That is why with MTU=4088 my router been performing flawlessly for the last 18 days, despite all the stress tests thrown it it.

I think it's worth to back-port the master branch patches (a long list...) to 4.14.93 (or whatever is the current release). There are 20 or so major code changes/patches submitted 2 since the 4.14 version. If I have some time I will try to generate a patch set and build a kernel.

Possible fixes:

torvalds/linux@fa0be0a#diff-11cf855fef243c84239e6e5a90c50fd1

torvalds/linux@4205c88#diff-11cf855fef243c84239e6e5a90c50fd1