<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 18, 2016 at 1:15 PM, Sven Eckelmann <span dir="ltr"><<a href="mailto:sven.eckelmann@open-mesh.com" target="_blank">sven.eckelmann@open-mesh.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">From: Sven Eckelmann <<a href="mailto:sven.eckelmann@open-mesh.com">sven.eckelmann@open-mesh.com</a>><br>
<br>
The port connected to the internal switch tends to drop a lot of packets<br>
when a lot of data is transferred over it. This is especially visible when<br>
IP fragmentation happens for large UDP and ICMP packets. An easy test for<br>
this is<br>
<br>
# works<br>
ping 192.168.1.23<br>
# doesn't work<br>
ping -s 65507 192.168.1.23<br>
<br>
But enabling flow control on ports without the builtin switch seems to<br>
break the connection completely in some situations. This was for example<br>
detected when a QCA955x with AR98533 on GMAC1 was started with an active<br>
link on this port. So only enable it for SoC ethernet devices with<br>
switch attached.<br>
<br>
This closes #19498<br>
<br>
Signed-off-by: Sven Eckelmann <<a href="mailto:sven.eckelmann@open-mesh.com">sven.eckelmann@open-mesh.com</a>><br>
---<br>
This is only an RFC because Felix reverted a similar change in r27034.<br>
Unfortunately, the revert commit doesn't contain enough information to<br>
find out if this problem would also happen when only activating flow<br>
control on the switch port port or when only enabling TX and not RX<br>
flow control (or the other way around).<br>
<br>
.../ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c | 6 +++++-<br>
1 file changed, 5 insertions(+), 1 deletion(-)<br>
<br>
diff --git a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c<br>
index 0832059..208b1d6 100644<br>
--- a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c<br>
+++ b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c<br>
@@ -455,7 +455,11 @@ static void ag71xx_hw_setup(struct ag71xx *ag)<br>
struct ag71xx_platform_data *pdata = ag71xx_get_pdata(ag);<br>
<br>
/* setup MAC configuration registers */<br>
- ag71xx_wr(ag, AG71XX_REG_MAC_CFG1, MAC_CFG1_INIT);<br>
+ if (pdata->is_ar724x && pdata->switch_data)<br>
+ ag71xx_wr(ag, AG71XX_REG_MAC_CFG1,<br>
+ MAC_CFG1_INIT | MAC_CFG1_TFC | MAC_CFG1_RFC);<br>
+ else<br>
+ ag71xx_wr(ag, AG71XX_REG_MAC_CFG1, MAC_CFG1_INIT);<br>
<br>
ag71xx_sb(ag, AG71XX_REG_MAC_CFG2,<br>
MAC_CFG2_PAD_CRC_EN | MAC_CFG2_LEN_CHECK);<br>
<span class=""><font color="#888888">--<br>
2.8.0.rc3<br>
_______________________________________________<br>
openwrt-devel mailing list<br>
<a href="mailto:openwrt-devel@lists.openwrt.org">openwrt-devel@lists.openwrt.org</a><br>
<a href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel" rel="noreferrer" target="_blank">https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel</a><br>
</font></span></blockquote></div><br></div><div class="gmail_extra"><div class="gmail_extra">It looks like you may have solved the original issue; this patch is working fine on WR-842ND v1. More details:</div><div class="gmail_extra"><br></div><div class="gmail_extra">* When I tried reverting r27034, the WAN port stopped functioning correctly, showing a tx timeout error - but the LAN ports still worked. With your patch, all ports work correctly.</div><div class="gmail_extra">* Your testcase (ping -s 65507 from/to a wired client between LAN ports) usually results in 20%-40% packet loss. With your patch (as with the original), it's now typically 0% packet loss between LAN ports.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Conn</div></div></div>