MT7621/MT7530: Ethernet RX/NAPI overload after upstream failure on DSA port, causing very high system CPU and loss of LAN connectivity

### Describe the bug

On a Cudy WR1300 v3 (ramips/mt7621, MT7621 + MT7530), an Ethernet port repurposed as a second WAN (`lan1`) can trigger severe kernel networking load when the upstream connection connected to that port fails.

The router has two independent WAN connections:

- WAN1: dedicated `wan` device
- WAN2: `lan1` DSA port connected to a FRITZ!Box
- Both WAN interfaces are managed by mwan3
- Normal Internet traffic is balanced 50/50
- If one WAN fails, mwan3 switches traffic to the remaining WAN

When WAN2 enters the problematic state, mwan3 correctly detects the connectivity failure and marks WAN2 offline. However, at approximately the same time, kernel networking load increases dramatically.

Typical symptoms are:

- system CPU usage rises dramatically, sometimes effectively saturating a CPU core
- `napi/mtk_eth-6`, `napi/mtk_eth-5` and/or `ksoftirqd/2` consume significant CPU
- wired LAN clients become unable to reliably reach even the OpenWrt router itself
- wired clients in VLAN 130 are particularly affected
- some Wi-Fi clients can sometimes still reach the router and the Internet
- SSH/LuCI access becomes unreliable or impossible
- forwarding becomes severely degraded
- the `lan1` Ethernet link itself still reports 1000 Mbps/full duplex and `Link detected: yes`
- no significant PHY errors, carrier errors or collisions are reported
- RX packet and drop rates on the common `eth0` interface increase significantly

This does not appear to be high CPU usage caused by the mwan3 userspace processes themselves. During the problem, the mwan3 processes consume essentially no CPU while kernel NAPI/softirq processing consumes the CPU.

Example during the failure:

```
CPU:   0% usr  32% sys   0% nic  40% idle   0% io   0% irq  26% sirq

PID  PPID USER STAT VSZ %VSZ %CPU COMMAND
28      2 root RW     0   0%  27% [ksoftirqd/2]
311     2 root RW     0   0%  15% [napi/mtk_eth-6]
310     2 root RW     0   0%   8% [napi/mtk_eth-5]
```

At other times `napi/mtk_eth-6` alone consumes approximately 25% of total CPU capacity while overall system CPU usage remains very high.

The physical Ethernet link does not appear to be incorrectly negotiated.

During the failure, `ethtool lan1` reports:

```
Advertised link modes:  1000baseT/Full
Advertised auto-negotiation: Yes

Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Link detected: yes
```

EEE is disabled:

```
EEE status: disabled
Tx LPI: disabled
```

The problem was also reproduced after restricting the local PHY advertisement to only `1000baseT/Full` while keeping autonegotiation enabled:

```
ethtool -s lan1 autoneg on advertise 0x020
```

Therefore a normal 10/100 Mbps downshift or duplex mismatch does not appear to explain the problem.

Software and hardware flow offloading were both disabled for testing:

```
flow_offloading='0'
flow_offloading_hw='0'
```

The problem still occurs.

During one measured failure, `lan1` counters changed over five seconds from:

```
RX packets: 576580067
RX dropped: 1064198
TX packets: 292394175
```

to:

```
RX packets: 576602629
RX dropped: 1064207
TX packets: 292409919
```

This corresponds to approximately:

```
lan1 RX: ~4,500 packets/sec
lan1 TX: ~3,150 packets/sec
```

More importantly, the common `eth0` interface changed over the same five-second interval from:

```
RX packets: 1241963956
RX dropped: 8622606
TX packets: 1459427028
```

to:

```
RX packets: 1242005836
RX dropped: 8628091
TX packets: 1459459969
```

This corresponds to approximately:

```
eth0 RX:  ~8,376 packets/sec
eth0 TX:  ~6,588 packets/sec
RX drops: ~1,097 packets/sec
```

`NET_RX` processing is heavily concentrated on CPU2.

Example:

```
NET_RX:
23482066 5487613 167458610 547690
```

Five seconds later:

```
NET_RX:
23484325 5487614 167466698 547696
```

The Ethernet IRQ counter also continues increasing rapidly:

```
1e100000.ethernet:
1059860428
```

Five seconds later:

```
1059866124
```

The most important isolation test is administratively disabling the affected DSA port:

```
ip link set lan1 down
```

After this, `lan1` correctly reports:

```
lan1@eth0: <BROADCAST,MULTICAST>
state DOWN
```

With `lan1` administratively down, the abnormal traffic/drop rate on the common `eth0` interface immediately disappears.

Measured over five seconds with `lan1` down:

Before:

```
RX packets: 1242474813
RX dropped: 8679363
TX packets: 1459862318
```

After five seconds:

```
RX packets: 1242475848
RX dropped: 8679363
TX packets: 1459862996
```

This corresponds to only:

```
RX:      ~207 packets/sec
TX:      ~136 packets/sec
RX drops: 0 packets/sec
```

compared with approximately:

```
RX:      ~8,376 packets/sec
TX:      ~6,588 packets/sec
RX drops: ~1,097 packets/sec
```

while the problematic `lan1` path was active.

CPU usage subsequently returns to normal.

Example after recovery:

```
CPU:   2% usr   1% sys   0% nic  94% idle   0% io   0% irq

napi/mtk_eth-6: 0%
napi/mtk_eth-5: 0%
ksoftirqd/2:    0%
```

This strongly suggests that the excessive RX/NAPI workload is triggered by traffic entering through the `lan1`/MT7530 path rather than by mwan3 itself.

The upstream device connected to `lan1` is a FRITZ!Box.

The problem occurs in connection with loss/failure of the WAN2 upstream connection.

mwan3 correctly detects the loss of connectivity:

```
Check (ping) failed for target(s) "8.8.8.8 1.1.1.1" on interface wan2 (lan1)
Interface wan2 (lan1) is disconnecting
Interface wan2 (lan1) is offline
```

and subsequently flushes the corresponding conntrack entries:

```
Selectively flushed conntrack entries for interface 'wan2' (mark 0x200/0x3f00)
```

The mwan3 userspace processes themselves do not show significant CPU usage during the failure.

An additional observation is that internal Ethernet communication is affected as well. For example, connections between the router and an internal host on `192.168.130.0/24` start failing even though this traffic does not require either WAN connection.

The router can become sufficiently overloaded that starting `tcpdump` after the problem has developed is difficult or impossible.

Recovery behaviour is also noteworthy:

- Simply restarting OpenWrt does not always immediately resolve the condition while the upstream FRITZ!Box remains in its problematic state.
- Physically disconnecting/reconnecting the Ethernet cable does not reliably produce immediate recovery.
- Powering off/restarting the upstream FRITZ!Box eventually causes the abnormal condition to disappear.
- Administratively disabling `lan1` immediately stops the abnormal RX/drop rate on `eth0`.
- After recovery, CPU usage returns to normal and the `napi/mtk_eth-*` threads become idle.

Conntrack exhaustion was checked and is not present.

Example:

```
nf_conntrack_count = 961
nf_conntrack_max   = 15360
```

The expected behaviour is that failure of an upstream connection on one MT7530 DSA port must not cause excessive NAPI/system CPU usage or make unrelated local Ethernet/VLAN interfaces unreachable.

The observed behaviour can be summarized as:

```
WAN2/upstream failure
        |
        v
traffic/problematic state on lan1 / MT7530
        |
        v
high eth0 RX/drop rate
        |
        v
mtk_eth NAPI / ksoftirqd load
        |
        v
very high system CPU
        |
        v
wired LAN connectivity becomes unreliable/unusable
```

Disabling `lan1` stops the abnormal RX/drop rate and the system subsequently recovers.

The available evidence therefore suggests an issue in or below the MT7621 Ethernet / MT7530 RX/NAPI data path, potentially triggered by traffic or a link-partner state generated by the upstream FRITZ!Box during an upstream connectivity failure.

I can provide additional diagnostics including:

- full OpenWrt configuration
- `dmesg`
- `logread`
- `/proc/interrupts`
- `/proc/softirqs`
- `ip -s link`
- `ethtool` output
- mwan3 configuration and status
- nftables ruleset

If MT7530 register dumps, `mtk_eth_soc` debug information, driver tracing, or other specific diagnostics are useful, please provide the commands to collect them.

### OpenWrt version

r33051-f5dae5ece4

### OpenWrt release

25.12.5

### OpenWrt target/subtarget

ramips/mt7621

### Device

Cudy WR1300 v3

### Image kind

Official downloaded image

### Steps to reproduce

1. Use a Cudy WR1300 v3 based on MediaTek MT7621 with the integrated MT7530 switch.

2. Configure two independent WAN connections:

   WAN1:
   - device: wan
   - IPv4: 192.168.2.2/24
   - gateway: 192.168.2.254

   WAN2:
   - device: lan1 (MT7530 DSA port repurposed as WAN)
   - IPv4: 192.168.3.2/24
   - gateway: 192.168.3.254

3. Connect `lan1` to a FRITZ!Box acting as the upstream router for WAN2.

4. Configure mwan3 to manage both WAN interfaces.

   Normal state:
   - WAN1 online
   - WAN2 online
   - 50/50 load balancing

   Failure state:
   - if WAN2 becomes unavailable, traffic should fail over to WAN1

5. Disable both software and hardware flow offloading:

```
flow_offloading='0'
flow_offloading_hw='0'
```

6. Verify that EEE is disabled on `lan1`:

```
ethtool --show-eee lan1
```

Expected:

```
EEE status: disabled
```

7. Optionally restrict `lan1` advertisement to 1000BASE-T Full while keeping autonegotiation enabled:

```
ethtool -s lan1 autoneg on advertise 0x020
```

Verify:

```
Advertised link modes:  1000baseT/Full
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Link detected: yes
```

The problem is reproducible with this setting as well.

8. Start with both WAN connections operating normally.

9. Cause the upstream Internet connection behind WAN2/FRITZ!Box to fail or wait until the WAN2 upstream connection fails naturally.

The Ethernet link between the FRITZ!Box and `lan1` may remain physically up at 1000 Mbps/full duplex.

10. mwan3 detects that its tracking targets are no longer reachable through WAN2:

```
Check (ping) failed for target(s) "8.8.8.8 1.1.1.1" on interface wan2 (lan1)
Interface wan2 (lan1) is disconnecting
Interface wan2 (lan1) is offline
```

11. Observe CPU usage:

```
top
```

After the failure develops, kernel networking threads such as the following consume significant CPU:

```
[napi/mtk_eth-6]
[napi/mtk_eth-5]
[ksoftirqd/2]
```

System and softirq CPU usage increase significantly and may make the router difficult to access.

12. Observe Ethernet counters:

```
ip -s link show lan1
ip -s link show eth0
```

During the problematic state, `eth0` receives thousands of packets per second and RX drops increase rapidly.

A measured example was approximately:

```
lan1 RX:      ~4,500 packets/sec
lan1 TX:      ~3,150 packets/sec

eth0 RX:      ~8,376 packets/sec
eth0 TX:      ~6,588 packets/sec
eth0 RX drop: ~1,097 packets/sec
```

13. Observe local network connectivity.

Wired clients, especially clients in VLAN 130, may become unable to reach even the OpenWrt router itself.

Some Wi-Fi clients may continue working or may work intermittently.

14. While the problem is active, administratively disable the affected DSA port:

```
ip link set lan1 down
```

15. Observe `eth0` counters again:

```
ip -s link show eth0
sleep 5
ip -s link show eth0
```

In a measured test, traffic immediately dropped to approximately:

```
eth0 RX:      ~207 packets/sec
eth0 TX:      ~136 packets/sec
eth0 RX drop: 0 packets/sec
```

16. Observe CPU usage again.

After the abnormal `lan1` traffic has stopped, CPU usage returns to normal and the `napi/mtk_eth-*`/`ksoftirqd` load disappears.

A measured recovered state was:

```
CPU:   2% usr   1% sys   0% nic  94% idle   0% io   0% irq
```

The problem has been reproduced multiple times.

### Actual behaviour

When the WAN2 upstream connection connected through the MT7530 `lan1` DSA port fails, the router can enter a severe kernel networking overload state.

mwan3 correctly detects that WAN2 has lost connectivity and marks the interface offline. The mwan3 userspace processes themselves do not consume significant CPU.

Instead, CPU time is consumed by the kernel Ethernet/NAPI receive path.

Observed processes include:

```
[napi/mtk_eth-6]
[napi/mtk_eth-5]
[ksoftirqd/2]
```

Example during the failure:

```
CPU:   0% usr  32% sys   0% nic  40% idle   0% io   0% irq  26% sirq

PID  PPID USER STAT VSZ %VSZ %CPU COMMAND
28      2 root RW     0   0%  27% [ksoftirqd/2]
311     2 root RW     0   0%  15% [napi/mtk_eth-6]
310     2 root RW     0   0%   8% [napi/mtk_eth-5]
```

At other times the system CPU load becomes sufficiently high that SSH, LuCI and even starting diagnostic tools such as tcpdump becomes difficult or impossible.

The Ethernet link itself continues to report a valid link:

```
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Link detected: yes
```

There is no corresponding increase in PHY errors, carrier errors or collisions.

During the failure, significant traffic and RX drops occur on the common `eth0` interface.

One measured five-second interval showed approximately:

```
lan1 RX:      ~4,500 packets/sec
lan1 TX:      ~3,150 packets/sec

eth0 RX:      ~8,376 packets/sec
eth0 TX:      ~6,588 packets/sec
eth0 RX drop: ~1,097 packets/sec
```

The excessive kernel networking load affects unrelated local Ethernet connectivity.

Wired clients, particularly clients in VLAN 130, may no longer be able to reliably reach the OpenWrt router itself, even though this traffic does not require WAN2.

Some Wi-Fi clients may continue to reach the router or Internet, although connectivity can be intermittent.

Administratively disabling the affected port with:

```
ip link set lan1 down
```

immediately stops the abnormal traffic/drop rate.

A measured five-second interval after disabling `lan1` showed approximately:

```
eth0 RX:      ~207 packets/sec
eth0 TX:      ~136 packets/sec
eth0 RX drop: 0 packets/sec
```

CPU usage subsequently returns to normal, for example:

```
CPU:   2% usr   1% sys   0% nic  94% idle   0% io   0% irq
```

Both software and hardware flow offloading have been disabled and the problem remains reproducible.

EEE is disabled.

Restricting PHY advertisement to only `1000baseT/Full` does not prevent the problem.

The observed behaviour therefore appears to involve the MT7621/MT7530 Ethernet RX/NAPI path associated with traffic entering through `lan1`, rather than CPU load generated directly by mwan3.

### Expected behaviour

A failure of the upstream Internet connection connected to `lan1` should not cause excessive CPU usage in the MT7621 Ethernet/NAPI receive path.

When WAN2 loses Internet connectivity:

1. The physical Ethernet link may remain up if the upstream router is still connected.

2. mwan3 should detect that WAN2 is unavailable.

3. mwan3 should remove WAN2 from the active load-balancing policy.

4. Existing connections using WAN2 may fail or be re-established through the remaining WAN as expected.

5. Traffic should fail over to WAN1.

6. Local Ethernet and VLAN connectivity must remain unaffected.

7. Wired clients must continue to be able to reach the OpenWrt router and other local VLANs according to the configured firewall rules.

8. `mtk_eth` NAPI threads and `ksoftirqd` should not consume excessive CPU merely because the upstream connection behind one MT7530 DSA port has failed.

9. The common `eth0` interface should not experience thousands of RX drops per second as a consequence of the WAN2 failure.

10. It should not be necessary to administratively disable `lan1`, restart the router, disconnect the Ethernet link, or restart/power-cycle the upstream FRITZ!Box to restore normal CPU usage and local network connectivity.

In short, failure of an upstream connection on one MT7530 DSA port should remain isolated to that WAN connection and must not overload the shared MT7621 Ethernet receive path or disrupt unrelated local Ethernet/VLAN traffic.

### Additional info

```
root@WR1300v3:~# ubus call system board
{
        "kernel": "6.12.94",
        "hostname": "WR1300v3",
        "system": "MediaTek MT7621 ver:1 eco:4",
        "model": "Cudy WR1300 v3",
        "board_name": "cudy,wr1300-v3",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "25.12.5",
                "firmware_url": "https://downloads.openwrt.org/",
                "revision": "r33051-f5dae5ece4",
                "target": "ramips/mt7621",
                "description": "OpenWrt 25.12.5 r33051-f5dae5ece4",
                "builddate": "1782737960"
        }
}
root@WR1300v3:~# 
root@WR1300v3:~# uname -a
Linux WR1300v3 6.12.94 #0 SMP Mon Jun 29 12:59:20 2026 mips GNU/Linux
root@WR1300v3:~# 
root@WR1300v3:~# apk list --installed | grep -E 'mwan3|fire
wall|kernel|kmod'
firewall4-2025.03.17~b6e51575-r2 mipsel_24kc {feeds/base/network/config/firewall4} (ISC) [installed]
kernel-6.12.94~35fb64ea09ee15c2f267bd5436b7f178-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-cfg80211-6.12.94.6.18.26-r1 mipsel_24kc {feeds/base/kernel/mac80211} (GPL-2.0-only) [installed]
kmod-crypto-acompress-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-aead-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-ccm-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-cmac-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-crc32c-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-ctr-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-gcm-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-geniv-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-gf128-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-ghash-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-hash-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-hmac-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-kpp-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-lib-chacha20-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-lib-chacha20poly1305-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-lib-curve25519-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-lib-poly1305-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-manager-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-null-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-rng-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-seqiv-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-sha3-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-crypto-sha512-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-gpio-button-hotplug-6.12.94-r5 mipsel_24kc {feeds/base/kernel/gpio-button-hotplug} (GPL-2.0) [installed]
kmod-hwmon-core-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-i2c-core-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-ipt-conntrack-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-ipt-core-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-leds-gpio-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-lib-crc-ccitt-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-lib-crc32c-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-lib-lzo-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-mac80211-6.12.94.6.18.26-r1 mipsel_24kc {feeds/base/kernel/mac80211} (GPL-2.0-only) [installed]
kmod-mt76-connac-6.12.94.2026.03.19~39c960c3-r2 mipsel_24kc {feeds/base/kernel/mt76} (BSD-3-Clause-Clear) [installed]
kmod-mt76-core-6.12.94.2026.03.19~39c960c3-r2 mipsel_24kc {feeds/base/kernel/mt76} (BSD-3-Clause-Clear) [installed]
kmod-mt7603-6.12.94.2026.03.19~39c960c3-r2 mipsel_24kc {feeds/base/kernel/mt76} (BSD-3-Clause-Clear) [installed]
kmod-mt7615-common-6.12.94.2026.03.19~39c960c3-r2 mipsel_24kc {feeds/base/kernel/mt76} (BSD-3-Clause-Clear) [installed]
kmod-mt7615e-6.12.94.2026.03.19~39c960c3-r2 mipsel_24kc {feeds/base/kernel/mt76} (BSD-3-Clause-Clear) [installed]
kmod-mt7663-firmware-ap-6.12.94.2026.03.19~39c960c3-r2 mipsel_24kc {feeds/base/kernel/mt76} (BSD-3-Clause-Clear) [installed]
kmod-nf-conntrack-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-nf-conntrack-netlink-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-nf-conntrack6-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-nf-flow-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-nf-ipt-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-nf-log-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-nf-log6-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-nf-nat-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-nf-reject-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-nf-reject6-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-nfnetlink-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-nft-core-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-nft-fib-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-nft-nat-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-nft-offload-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-ppp-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-pppoe-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-pppox-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-slhc-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-udptunnel4-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-udptunnel6-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
kmod-wireguard-6.12.94-r1 mipsel_24kc {feeds/base/kernel/linux} (GPL-2.0-only) [installed]
luci-app-firewall-26.207.72448~3727980 noarch {feeds/luci/feeds/luci/applications/luci-app-firewall} (Apache-2.0) [installed]
luci-app-mwan3-26.999.3.6.10-r1 noarch {/feed/applications/luci-app-mwan3} (GPL-2.0) [installed]
mwan3-3.6.11-r1 mipsel_24kc {/feed/mwan3} (GPL-2.0) [installed]
root@WR1300v3:~# 
root@WR1300v3:~# dmesg | grep -Ei 'mtk|mt7530|ethernet|watc
hdog|timeout'
[    1.787380] mt7530-mdio mdio-bus:1f: MT7530 adapts as multi-chip module
[    1.804294] mtk_soc_eth 1e100000.ethernet eth0: mediatek frame engine at 0xbe100000, irq 19
[    1.815902] mtk_soc_eth 1e100000.ethernet eth1: mediatek frame engine at 0xbe100000, irq 19
[    1.902466] mt7530-mdio mdio-bus:1f: MT7530 adapts as multi-chip module
[    1.934987] mt7530-mdio mdio-bus:1f: configuring for fixed/rgmii link mode
[    1.942596] mt7530-mdio mdio-bus:1f: Link is Up - 1Gbps/Full - flow control rx/tx
[    1.944951] mt7530-mdio mdio-bus:1f lan4 (uninitialized): PHY [mt7530-0:00] driver [MediaTek MT7530 PHY] (irq=21)
[    1.963742] mt7530-mdio mdio-bus:1f lan3 (uninitialized): PHY [mt7530-0:01] driver [MediaTek MT7530 PHY] (irq=22)
[    1.976615] mt7530-mdio mdio-bus:1f lan2 (uninitialized): PHY [mt7530-0:02] driver [MediaTek MT7530 PHY] (irq=23)
[    1.989525] mt7530-mdio mdio-bus:1f lan1 (uninitialized): PHY [mt7530-0:03] driver [MediaTek MT7530 PHY] (irq=24)
[    2.002241] mtk_soc_eth 1e100000.ethernet eth0: entered promiscuous mode
[    2.748630] init: - watchdog -
[    4.961915] mtk_soc_eth 1e100000.ethernet wan: renamed from eth1
[    6.860361] mtk_soc_eth 1e100000.ethernet eth0: configuring for fixed/rgmii link mode
[    6.872931] mtk_soc_eth 1e100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[    6.873381] mt7530-mdio mdio-bus:1f lan1: configuring for phy/gmii link mode
[   10.260715] mt7530-mdio mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control off
[   12.039559] mt7530-mdio mdio-bus:1f lan1: Link is Down
[   12.059671] procd: - watchdog -
[   12.741259] procd: - watchdog -
[   31.479678] mtk_soc_eth 1e100000.ethernet eth0: Link is Down
[   31.510203] mtk_soc_eth 1e100000.ethernet eth0: configuring for fixed/rgmii link mode
[   31.511009] mtk_soc_eth 1e100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[   31.520598] mt7530-mdio mdio-bus:1f lan2: configuring for phy/gmii link mode
[   31.522719] mt7530-mdio mdio-bus:1f lan2: entered allmulticast mode
[   31.522764] mtk_soc_eth 1e100000.ethernet eth0: entered allmulticast mode
[   31.532019] mt7530-mdio mdio-bus:1f lan2: entered promiscuous mode
[   31.572027] mt7530-mdio mdio-bus:1f lan3: configuring for phy/gmii link mode
[   31.574791] mt7530-mdio mdio-bus:1f lan3: entered allmulticast mode
[   31.578373] mt7530-mdio mdio-bus:1f lan3: entered promiscuous mode
[   31.611972] mt7530-mdio mdio-bus:1f lan4: configuring for phy/gmii link mode
[   31.614162] mt7530-mdio mdio-bus:1f lan4: entered allmulticast mode
[   31.617228] mt7530-mdio mdio-bus:1f lan4: entered promiscuous mode
[   31.687124] mtk_soc_eth 1e100000.ethernet wan: PHY [mt7530-0:04] driver [MediaTek MT7530 PHY] (irq=POLL)
[   31.687212] mtk_soc_eth 1e100000.ethernet wan: configuring for phy/rgmii link mode
[   31.711087] mt7530-mdio mdio-bus:1f lan1: configuring for phy/gmii link mode
[   34.714456] mt7530-mdio mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control off
[   34.776822] mt7530-mdio mdio-bus:1f lan4: Link is Up - 1Gbps/Full - flow control off
[   34.835070] mt7530-mdio mdio-bus:1f lan3: Link is Up - 1Gbps/Full - flow control rx/tx
[   34.960606] mt7530-mdio mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control off
[   35.814952] mtk_soc_eth 1e100000.ethernet wan: Link is Up - 1Gbps/Full - flow control off
[   43.861275] mtk_soc_eth 1e100000.ethernet wan: entered allmulticast mode
[   76.204619] mt7530-mdio mdio-bus:1f lan1: Link is Down
[   89.367605] mt7530-mdio mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control off
[   92.070287] mt7530-mdio mdio-bus:1f lan2: Link is Down
[   94.764173] mt7530-mdio mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control off
[  143.323804] mt7530-mdio mdio-bus:1f lan1: Link is Down
[  149.477335] mt7530-mdio mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control off
[  149.480400] mt7530-mdio mdio-bus:1f lan2: Link is Down
[  152.133660] mt7530-mdio mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control off
[  154.976192] mt7530-mdio mdio-bus:1f lan1: Link is Down
[  165.506079] mt7530-mdio mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control off
[  199.709228] mt7530-mdio mdio-bus:1f lan1: Link is Down
[  227.622293] mt7530-mdio mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control off
[  289.876316] mt7530-mdio mdio-bus:1f lan1: entered promiscuous mode
[  296.503313] mt7530-mdio mdio-bus:1f lan1: left promiscuous mode
[  853.927606] mt7530-mdio mdio-bus:1f lan1: Link is Down
[  857.625627] mt7530-mdio mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control off
[16908.072465] mt7530-mdio mdio-bus:1f lan2: Link is Down
[16910.856023] mt7530-mdio mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control off
[16915.401631] mt7530-mdio mdio-bus:1f lan2: Link is Down
[16918.136084] mt7530-mdio mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control off
[173322.751050] mtk_soc_eth 1e100000.ethernet wan: entered promiscuous mode
[173333.219505] mt7530-mdio mdio-bus:1f lan1: entered promiscuous mode
[173383.324652] mt7530-mdio mdio-bus:1f lan1: left promiscuous mode
[173384.379863] mtk_soc_eth 1e100000.ethernet wan: left promiscuous mode
[173743.443415] mtk_soc_eth 1e100000.ethernet wan: entered promiscuous mode
[173777.985386] mtk_soc_eth 1e100000.ethernet wan: left promiscuous mode
[173806.436560] mtk_soc_eth 1e100000.ethernet wan: entered promiscuous mode
[173813.409313] mtk_soc_eth 1e100000.ethernet wan: left promiscuous mode
[173905.195334] mtk_soc_eth 1e100000.ethernet wan: entered promiscuous mode
[173923.055690] mt7530-mdio mdio-bus:1f lan1: entered promiscuous mode
[173945.497858] mt7530-mdio mdio-bus:1f lan1: left promiscuous mode
[173946.614260] mtk_soc_eth 1e100000.ethernet wan: left promiscuous mode
[175527.509811] mtk_soc_eth 1e100000.ethernet wan: entered promiscuous mode
[175561.613883] mtk_soc_eth 1e100000.ethernet wan: left promiscuous mode
[276934.753783] mt7530-mdio mdio-bus:1f lan2: Link is Down
[276937.534490] mt7530-mdio mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control off
[286727.065414] mt7530-mdio mdio-bus:1f lan2: Link is Down
[286729.869280] mt7530-mdio mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control off
[286730.681473] mt7530-mdio mdio-bus:1f lan2: Link is Down
[286733.496466] mt7530-mdio mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control off
[286734.406263] mt7530-mdio mdio-bus:1f lan2: Link is Down
[286737.173642] mt7530-mdio mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control off
[286739.438696] mt7530-mdio mdio-bus:1f lan2: Link is Down
[286742.206879] mt7530-mdio mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control off
[286743.121142] mt7530-mdio mdio-bus:1f lan2: Link is Down
[286745.936610] mt7530-mdio mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control off
[286746.845575] mt7530-mdio mdio-bus:1f lan2: Link is Down
[286749.544137] mt7530-mdio mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control off
[286750.915067] mt7530-mdio mdio-bus:1f lan2: Link is Down
[286753.219547] mt7530-mdio mdio-bus:1f lan2: Link is Up - 100Mbps/Full - flow control off
[380922.652631] mt7530-mdio mdio-bus:1f lan2: Link is Down
[380925.660304] mt7530-mdio mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control off
[380926.475698] mt7530-mdio mdio-bus:1f lan2: Link is Down
[380932.608198] mt7530-mdio mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control off
[380933.521957] mt7530-mdio mdio-bus:1f lan2: Link is Down
[380935.552512] mt7530-mdio mdio-bus:1f lan2: Link is Up - 100Mbps/Full - flow control off
[690468.574070] mt7530-mdio mdio-bus:1f lan1: Link is Down
[690755.435731] mt7530-mdio mdio-bus:1f lan1: configuring for phy/gmii link mode
[690758.676688] mt7530-mdio mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control off
[690785.012918] mtk_soc_eth 1e100000.ethernet wan: Link is Down
[690797.493485] mtk_soc_eth 1e100000.ethernet wan: Link is Up - 1Gbps/Full - flow control off
[690831.812932] mtk_soc_eth 1e100000.ethernet wan: Link is Down
[690859.893841] mtk_soc_eth 1e100000.ethernet wan: Link is Up - 1Gbps/Full - flow control off
root@WR1300v3:~# 
root@WR1300v3:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='25.12.5'
DISTRIB_REVISION='r33051-f5dae5ece4'
DISTRIB_TARGET='ramips/mt7621'
DISTRIB_ARCH='mipsel_24kc'
DISTRIB_DESCRIPTION='OpenWrt 25.12.5 r33051-f5dae5ece4'
DISTRIB_TAINTS=''
root@WR1300v3:~# 
root@WR1300v3:~# cat /etc/os-release
NAME="OpenWrt"
VERSION="25.12.5"
ID="openwrt"
ID_LIKE="lede openwrt"
PRETTY_NAME="OpenWrt 25.12.5"
VERSION_ID="25.12.5"
HOME_URL="https://openwrt.org/"
BUG_URL="https://bugs.openwrt.org/"
SUPPORT_URL="https://forum.openwrt.org/"
FIRMWARE_URL="https://downloads.openwrt.org/"
BUILD_ID="r33051-f5dae5ece4"
OPENWRT_BOARD="ramips/mt7621"
OPENWRT_ARCH="mipsel_24kc"
OPENWRT_TAINTS=""
OPENWRT_DEVICE_MANUFACTURER="OpenWrt"
OPENWRT_DEVICE_MANUFACTURER_URL="https://openwrt.org/"
OPENWRT_DEVICE_PRODUCT="Generic"
OPENWRT_DEVICE_REVISION="v0"
OPENWRT_RELEASE="OpenWrt 25.12.5 r33051-f5dae5ece4"
OPENWRT_BUILD_DATE="1782737960"
```

### Diffconfig

```text

```

### Terms

- [x] I am reporting an issue for OpenWrt, not an unsupported fork.

Navigation Menu

Uh oh!

MT7621/MT7530: Ethernet RX/NAPI overload after upstream failure on DSA port, causing very high system CPU and loss of LAN connectivity #25162

Describe the bug

OpenWrt version

OpenWrt release

OpenWrt target/subtarget

Device

Image kind

Steps to reproduce

Actual behaviour

Expected behaviour

Additional info

Diffconfig

Terms

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Uh oh!

MT7621/MT7530: Ethernet RX/NAPI overload after upstream failure on DSA port, causing very high system CPU and loss of LAN connectivity #25162

Description

Describe the bug

OpenWrt version

OpenWrt release

OpenWrt target/subtarget

Device

Image kind

Steps to reproduce

Actual behaviour

Expected behaviour

Additional info

Diffconfig

Terms

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions