| Message ID | 20200609133504.6563-1-sven@narfation.org |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | [OpenWrt-Devel,v2] ipq40xx: essedma: Disable TCP segmentation offload for IPv6 | expand |
On 09.06.20 15:35, Sven Eckelmann wrote: > It was noticed that the the whole MAC can hang when transferring data from > one ar40xx port (WAN ports) to the CPU and from the CPU back to another > ar40xx port (LAN ports). The CPU was doing only NATing in that process. > > Usually, the problem first starts with a simple data corruption: > > $ wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.4.0-amd64-netinst.iso -O /dev/null > ... > Connecting to saimei.ftp.acc.umu.se (saimei.ftp.acc.umu.se)|2001:6b0:19::138|:443... connected. > ... > Read error at byte 48807936/352321536 (Decryption has failed.). Retrying. > > But after a short while, the whole MAC will stop to react. No traffic can > be transported anymore from the CPU port from/to the AR40xx PHY/switch and > the MAC has to be resetted. > > Signed-off-by: Sven Eckelmann <sven@narfation.org> Acked-by: John Crispin <john@phrozen.org> > --- > v2: > * move the changes directly to > target/linux/ipq40xx/files-5.4/drivers/net/ethernet/qualcomm/essedma/edma_axi.c > > The problem was first observed on OpenWrt 18.06 and OpenWrt 19.07. It would > be good that the patch (or maybe even a better one) is "backported". This > actually means copying the one from the v1 [1] to the correct ipq40xx patch > folder and then refresh the patch. > > Thanks > > [1] https://patchwork.ozlabs.org/project/openwrt/patch/20200609132304.31669-1-sven@narfation.org/ > > .../drivers/net/ethernet/qualcomm/essedma/edma_axi.c | 11 ++++------- > 1 file changed, 4 insertions(+), 7 deletions(-) > > diff --git a/target/linux/ipq40xx/files-5.4/drivers/net/ethernet/qualcomm/essedma/edma_axi.c b/target/linux/ipq40xx/files-5.4/drivers/net/ethernet/qualcomm/essedma/edma_axi.c > index b619bbbab9..96a82b3116 100644 > --- a/target/linux/ipq40xx/files-5.4/drivers/net/ethernet/qualcomm/essedma/edma_axi.c > +++ b/target/linux/ipq40xx/files-5.4/drivers/net/ethernet/qualcomm/essedma/edma_axi.c > @@ -970,17 +970,14 @@ static int edma_axi_probe(struct platform_device *pdev) > edma_netdev[i]->features = NETIF_F_HW_CSUM | NETIF_F_RXCSUM > | NETIF_F_HW_VLAN_CTAG_TX > | NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_SG | > - NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_GRO; > + NETIF_F_TSO | NETIF_F_GRO; > edma_netdev[i]->hw_features = NETIF_F_HW_CSUM | NETIF_F_RXCSUM | > NETIF_F_HW_VLAN_CTAG_RX > - | NETIF_F_SG | NETIF_F_TSO | NETIF_F_TSO6 | > - NETIF_F_GRO; > + | NETIF_F_SG | NETIF_F_TSO | NETIF_F_GRO; > edma_netdev[i]->vlan_features = NETIF_F_HW_CSUM | NETIF_F_SG | > - NETIF_F_TSO | NETIF_F_TSO6 | > - NETIF_F_GRO; > + NETIF_F_TSO | NETIF_F_GRO; > edma_netdev[i]->wanted_features = NETIF_F_HW_CSUM | NETIF_F_SG | > - NETIF_F_TSO | NETIF_F_TSO6 | > - NETIF_F_GRO; > + NETIF_F_TSO | NETIF_F_GRO; > > #ifdef CONFIG_RFS_ACCEL > edma_netdev[i]->features |= NETIF_F_RXHASH | NETIF_F_NTUPLE; >
diff --git a/target/linux/ipq40xx/files-5.4/drivers/net/ethernet/qualcomm/essedma/edma_axi.c b/target/linux/ipq40xx/files-5.4/drivers/net/ethernet/qualcomm/essedma/edma_axi.c index b619bbbab9..96a82b3116 100644 --- a/target/linux/ipq40xx/files-5.4/drivers/net/ethernet/qualcomm/essedma/edma_axi.c +++ b/target/linux/ipq40xx/files-5.4/drivers/net/ethernet/qualcomm/essedma/edma_axi.c @@ -970,17 +970,14 @@ static int edma_axi_probe(struct platform_device *pdev) edma_netdev[i]->features = NETIF_F_HW_CSUM | NETIF_F_RXCSUM | NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_SG | - NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_GRO; + NETIF_F_TSO | NETIF_F_GRO; edma_netdev[i]->hw_features = NETIF_F_HW_CSUM | NETIF_F_RXCSUM | NETIF_F_HW_VLAN_CTAG_RX - | NETIF_F_SG | NETIF_F_TSO | NETIF_F_TSO6 | - NETIF_F_GRO; + | NETIF_F_SG | NETIF_F_TSO | NETIF_F_GRO; edma_netdev[i]->vlan_features = NETIF_F_HW_CSUM | NETIF_F_SG | - NETIF_F_TSO | NETIF_F_TSO6 | - NETIF_F_GRO; + NETIF_F_TSO | NETIF_F_GRO; edma_netdev[i]->wanted_features = NETIF_F_HW_CSUM | NETIF_F_SG | - NETIF_F_TSO | NETIF_F_TSO6 | - NETIF_F_GRO; + NETIF_F_TSO | NETIF_F_GRO; #ifdef CONFIG_RFS_ACCEL edma_netdev[i]->features |= NETIF_F_RXHASH | NETIF_F_NTUPLE;
It was noticed that the the whole MAC can hang when transferring data from one ar40xx port (WAN ports) to the CPU and from the CPU back to another ar40xx port (LAN ports). The CPU was doing only NATing in that process. Usually, the problem first starts with a simple data corruption: $ wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.4.0-amd64-netinst.iso -O /dev/null ... Connecting to saimei.ftp.acc.umu.se (saimei.ftp.acc.umu.se)|2001:6b0:19::138|:443... connected. ... Read error at byte 48807936/352321536 (Decryption has failed.). Retrying. But after a short while, the whole MAC will stop to react. No traffic can be transported anymore from the CPU port from/to the AR40xx PHY/switch and the MAC has to be resetted. Signed-off-by: Sven Eckelmann <sven@narfation.org> --- v2: * move the changes directly to target/linux/ipq40xx/files-5.4/drivers/net/ethernet/qualcomm/essedma/edma_axi.c The problem was first observed on OpenWrt 18.06 and OpenWrt 19.07. It would be good that the patch (or maybe even a better one) is "backported". This actually means copying the one from the v1 [1] to the correct ipq40xx patch folder and then refresh the patch. Thanks [1] https://patchwork.ozlabs.org/project/openwrt/patch/20200609132304.31669-1-sven@narfation.org/ .../drivers/net/ethernet/qualcomm/essedma/edma_axi.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-)