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>
of_get_mac_address returns valid pointer or ERR_PTR since 5.2 via commit
d01f449c008a ("of_net: add NVMEM support to of_get_mac_address") so the
patch fixes following OOPs on nbg6617:
Unable to handle kernel paging request at virtual address ffffffed
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.4.24 #0
PC is at edma_axi_probe+0x444/0x1114
LR is at bus_find_device+0x88/0x9c
Where the PC can be resolved to:
>>> l *edma_axi_probe+0x444
0xc067be5c is in edma_axi_probe (./include/linux/string.h:378).
>>> l *edma_axi_probe+0x43f
0xc067be57 is in edma_axi_probe (drivers/net/ethernet/qualcomm/essedma/edma_axi.c:936)
Which leads to the following code fragment:
935 mac_addr = of_get_mac_address(pnp);
936 if (mac_addr)
937 memcpy(edma_netdev[idx_mac]->dev_addr, mac_addr, ETH_ALEN);
Where using mac_addr=0xffffffed (-ENODEV) as source address in memcpy()
is causing the OOPs.
Acked-by: John Crispin <john@phrozen.org>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Sven Eckelmann