--- Begin Message ---
Hi Petr,
Quoting Petr Štetiar <yn...@true.cz>:
Looking at the current upstream driver implementation, it seems like the
TX/RX flow control is enabled only if the flow control pause option is
resolved from the device/link partner advertisements (or otherwise set).
With upstream you mean mainline 5.5 kernel?
In the DTS the CPU port is defined as a fixed-link with pause enabled.
So the pause bits are always resolved/set.
I can't tell if the mainline kernel driver encounters the same issue.
I don't use my device daily.
I still wonder if there is any race condition in the TX path/handling.
I see in the mainline kernel version they are using the same lock in
tx_map and
tx_poll. And also checking the DMA owner bit in the descriptor.
So I think that the following is happening.
The hardware can't send the frames fast enough because of the PAUSE frames,
maybe to a slower device? The CPU is filling the tx ring faster then the
hardware sending it and eventually CPU overtakes the DMA head. Which causes an
issue/race/deadlock.
By disabling the PAUSE/flow control, it is less likely that is overtake is
going happen. But may result in more packet loss.
On the other hand, our current in-tree driver force enables TX/RX
flow control by default, thus possibly leading to TX timeouts if the
other end sends pause frames (which are not properly handled?):
WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:320
dev_watchdog+0x1ac/0x324
NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
Disabling the flow control on PORT 5 MAC seems to fix this issues as the
pause frames are then filtered out. While at it, I'm removing the if
condition completely as suggested, since this code is run only on mt7621
SoC, so there is no need to check for the silicon revisions.
Port 6 is connected to the first GMAC of the SOC, not port 5.
So it should be PORT 6 in your description also you change the first GMAC
settings, maybe mention that too.
Greats,
René
Ref:
https://lists.openwrt.org/pipermail/openwrt-devel/2017-November/009882.html
Ref:
https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/50000/12
Suggested-by: Felix Fietkau <n...@nbd.name>
Reported-by: Rosen Penev <ros...@gmail.com>
Signed-off-by: Petr Štetiar <yn...@true.cz>
---
.../drivers/net/ethernet/mediatek/gsw_mt7621.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git
a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt7621.c
b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt7621.c
index 89be23900738..232bcd8cf4ea 100644
---
a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt7621.c
+++
b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt7621.c
@@ -98,15 +98,9 @@ static void mt7621_hw_init(struct mt7620_gsw
*gsw, struct device_node *np)
mt7530_mdio_w32(gsw, 0x7000, 0x3);
usleep_range(10, 20);
- if ((rt_sysc_r32(SYSC_REG_CHIP_REV_ID) & 0xFFFF) == 0x0101) {
- /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */
- mtk_switch_w32(gsw, 0x2305e30b, GSW_REG_MAC_P0_MCR);
- mt7530_mdio_w32(gsw, 0x3600, 0x5e30b);
- } else {
- /* (GE1, Force 1000M/FD, FC ON, MAX_RX_LENGTH 1536) */
- mtk_switch_w32(gsw, 0x2305e33b, GSW_REG_MAC_P0_MCR);
- mt7530_mdio_w32(gsw, 0x3600, 0x5e33b);
- }
+ /* (GE1, Force 1000M/FD, FC OFF, MAX_RX_LENGTH 1536) */
+ mtk_switch_w32(gsw, 0x2305e30b, GSW_REG_MAC_P0_MCR);
+ mt7530_mdio_w32(gsw, 0x3600, 0x5e30b);
/* (GE2, Link down) */
mtk_switch_w32(gsw, 0x8000, GSW_REG_MAC_P1_MCR);
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--- End Message ---
