[BPI-R4 Pro / MT7988A] WAN TX (upload from router) is extremely slow / stalls, while RX is fine

[jdelrue]

[BPI-R4 Pro / MT7988A] WAN TX (upload from router) is extremely slow / stalls, while RX is fine

Summary

On Banana Pi BPI-R4 Pro (MT7988A), WAN RX path is fine but WAN TX path is severely degraded (often near-zero or stalls).

• Upload from client to router / host->device path: generally fine
• Upload from router to WAN / device->host path: very slow or stalls

This persists on kernel 6.18.18-bpi-r4-main after multiple tuning attempts.

Hardware / Topology

• Board: BPI-R4 Pro
• SoC: MT7988A
• WAN: GMAC1 (USXGMII path)
• WAN PHY: Aeonsemi AS21xxx (PHYAD 28)
• Kernel driver: mtk_soc_eth

Software / Build Context

• Project branch tested: BPI-Router-Linux 6.18-main
• Problem observed on multiple flashed devices/IPs during iterative testing
• Testing was performed with both Ubuntu-based and OpenWrt-based images (OpenWrt used as comparison baseline)
• On the official Banana Pi OpenWrt build from https://docs.banana-pi.org/en/BPI-R4_Pro/BananaPi_BPI-R4_Pro, we do not observe this WAN TX/upload problem.

Symptoms

• WAN link comes up at 1000Mb/s Full
• WAN upload behavior (router TX) is poor: transfers stall or become near-zero
• WAN download behavior (router RX) is normal

Observed stats while reproducing:

• tx_skip: 0
• No obvious TX error counters rising
• rx_fcs_errors / rx_short_errors are present but link became much more stable after PHY firmware update

What was tested

1) PHY firmware update (important result)

• Updated AS21xxx firmware from 1.8.5 to 1.9.1
• Result:
  • major link-flap improvement (carrier_changes dropped drastically)
  • WAN TX/upload issue remained

Boot logs show:

• Aeonsemi AS21xxx ... Firmware Version: 1.9.1

2) DPC rate adaptation in AS21xxx driver

• Tried enabling DPC RA in drivers/net/phy/as21xxx.c (it was previously disabled)
• Result:
  • WAN fully broke (no traffic)
  • Reverted immediately
• Noted there is an upstream/vendor-side commit disabling this in this code path.

3) Offload toggles (runtime)

• Disabled on WAN at runtime:
  • tso off, gso off, sg off (and also tested with GRO off)
• Result:
  • no meaningful fix for TX stall behavior

4) Quick directional transfer tests

Small, bounded tests used to avoid long runs:

• 512KB both directions: usually succeeds
• 5MB device->host (TX path): often stalls/timeouts
• 5MB host->device (RX path): succeeds

This strongly indicates directional TX-path issue.

Driver/code analysis findings

A) USXGMII PCS behavior looked suspicious

In drivers/net/pcs/pcs-mtk-usxgmii.c, pcs_get_state() was reconfiguring PCS when link looked down.

A patch was tested to move recovery to delayed polling instead of inline reset.

B) NAPI poll weight

MTK SDK has a patch increasing NAPI weight to 256.

C) GMAC1 force-mode handling

Compared against MTK SDK xgmac force-mode handling.

Build combinations tested

• Build including:
  • NAPI poll weight change to 256
  • USXGMII PCS recovery changed to delayed polling instead of inline reset
• Build initially without the GMAC1 force-mode handling adjustment, then later added for further test cycle

Current status

• Link stability improved significantly after PHY fw 1.9.1
• WAN TX/upload issue still reproducible in current tests
• Problem appears specific to TX path under this GMAC1/USXGMII setup on 6.18 stack

Useful runtime observations

• ethtool -i wan: mtk_soc_eth
• Link state commonly reports: 1000Mb/s Full
• tx_skip stays zero
• Intermittent WAN link down/up events can still occur over long uptime, but not enough to explain near-zero TX behavior alone

---

If needed, I can provide full dmesg + ethtool dumps from a fresh boot and from a failing transfer window.

[frank-w]

Thank you for the findings

The as21 phys only working a bit with downstream driver... upstream is not working. I'm no phy/network expert. This has to be targeted to aeonsemi/mtk/bpi not towards my repo.