[mt7915] mac80211 WARN at rx.c:5373 during DBDC reconfigure on MT7621 (Netis N6, MT7975DN)

[PrEvIeS]

Hardware

• Board: Netis N6 (ramips/mt7621)
• WiFi chip: MediaTek MT7915E + MT7975DN front-end (DBDC, single PCIe function 0000:02:00.0)
• Architecture: mipsel_24kc
• Firmware: WM ROM patch v0.1.0.10 / WA ROM patch v0.0.0.10 / WM firmware v1.6.10.6 / WA firmware v1.6.10.6

Software

• OpenWrt 25.12.2 (stock, official build)
• Kernel 6.12.74
• mac80211 from backports-6.18.7
• WED disabled (/sys/module/mt7915e/parameters/wed_enable = N)

Symptom

Any DBDC reconfigure (wifi reload, wifi down; wifi up) with both radios enabled produces WARNING at backports-6.18.7/net/mac80211/rx.c:5373 cascading into both phys becoming zombie netdevs without hostapd backing.

After the warning, hostapd reports:

phy1-ap0: AP-DISABLED
hostapd.add_iface failed for phy phy1 ifname=phy1-ap0
Failed to set beacon parameters    (repeats)
phy0-ap0: INTERFACE-DISABLED        <- 2.4GHz also collapses

Result: iw dev shows both phyN-ap0 with txpower 20 dBm but ubus call hostapd.phyN-ap0 get_status returns "Not found", tx-bytes=0, multicast TXQ all zeros.

Stack trace excerpt

WARNING: CPU: 3 PID: 1045 at backports-6.18.7/net/mac80211/rx.c:5373
Comm: napi/phy0-7
Call Trace:
  mt76+0xe000
  mac80211@+0x92000

Reproduction

1. Configure both radios in /etc/config/wireless with disabled=0 (radio0 = 2.4G HE40, radio1 = 5G HE80, both WPA2-PSK).
2. wifi reload (or wifi down && sleep 3 && wifi up).
3. Observe rx.c:5373 WARN within 1-2 seconds; phy1-ap0 fails to come up; phy0-ap0 is dragged down with it.

Recovery requires either reboot or rmmod mt7915e; modprobe mt7915e — but on Netis N6 the rmmod recipe causes phy renumbering (phy0/1 → phy2/3) that breaks netifd UCI device-path bindings (path='1e140000.pcie/.../0000:02:00.0+0' no longer matches), leaving 2.4GHz unrecoverable until reboot.

Configuration that works

Disabling radio1 (5GHz) entirely and operating 2.4GHz only — single-radio bring-up does not trigger the WARN.

Possibly related

Issue #1067 reports a similar mt76_dma_rx_poll / mt7915_rx_check WARN cascade on MT7986 + ImmortalWrt 24.10.5 / kernel 6.6.122; @simonchen has been testing memory-barrier patches in mt76_dma_rx_poll / mt76_dma_tx_cleanup specifically on MT7621 + MT7915 hardware (matching this report), claiming 9+ hours of stability vs. ~8 hours to crash without patches.

The crash here is one layer up the stack — mac80211/rx.c:5373 is in IEEE80211_SKB_CB / chanctx validation, not in mt7915_mac_wtbl_lmac_addr or mt7915_rx_check. But the trigger pattern is the same: race in RX path during reconfigure on the MT7621 SMP DMA. If the underlying cause is stale cache with corrupted pointers, the same memory barriers could plausibly close this window too.

Notes

• Regression appeared between OpenWrt 25.12.0 (works fine) and 25.12.1 / 25.12.2 (broken). Bisect against backports-6.18.7 changes to mac80211 RX path would be informative.
• Single-PCIe-function DBDC chips (MT7905DAN + MT7975DN) seem disproportionately affected — the MT7975DN front-end is shared across Cudy X6 v2, Belkin RT3200 and others; OpenWrt forum thread 244026 (Cudy X6 v2) reports the same regression class with the validated rmmod workaround.
• Setting noscan=1 on radio0 and pinning htmode=HE40 on 2.4GHz had no effect on the 5GHz bring-up failure.

cc @simonchen (related work in #1059 / #1067)