The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
--- Begin Message ---
Quoting René van Dorst <opensou...@vdorst.com>:
Quoting René van Dorst <opensou...@vdorst.com>:
Quoting Petr Štetiar <yn...@true.cz>:
René van Dorst via openwrt-devel <openwrt-devel@lists.openwrt.org>
[2020-02-11 15:59:52]:
[adding Kristian to the Cc: loop]
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?
Yes, 5.6-rc1
In the DTS the CPU port is defined as a fixed-link with pause enabled.
So the pause bits are always resolved/set.
I see[1] port@6 with fixed-link, without pause property.
Here is more information I wrote [1] about the mt7530 switch and it
modes and also
the mt7621 example below. I used the pause because AFAIK there
was/is no pause issue.
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.
Probably, I didn't tried to reproduce it or planning to do so.
I hope to reproduce it quick by reducing the TX ring size from 4096 to 256.
Hi Petr,
I thing I looking in the right direction.
With this patch, reducing the tx_ring size to 4 * 4 = 16 packets, I
can easily
trigger a transmit timeout.
Just create some traffic.
Hi Petr,
Although it triggers the timeout, it seems the driver/functions don't expected
such small dma sizes. With some extra debug code added, I see that only the
first 2 entries are filled and a timeout hits. By increasing the size
to 8*4=32
packets the drivers works as expected.
I tried to flood the device with packets. Iperf3 (LAN->WAN) through the device
with and in parallel iperf3 from device to LAN. After more then +500GBytes it
was still going.
So I am not sure about my theory.
Maybe we could add some extra debug code in the timeout().
FE can set the flag "DMA DONE" for every packet that was send.
Debug code should show that bit for every entry.
Maybe this gives a bit more info.
Greats,
René
rene@pc-rene:~/dev/openwrt$ git diff
diff --git
a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index c6f4d90193b3..09d5e75ec0b0 100644
---
a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++
b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1658,7 +1658,7 @@ static int fe_probe(struct platform_device *pdev)
priv->msg_enable = netif_msg_init(fe_msg_level,
FE_DEFAULT_MSG_ENABLE);
priv->rx_ring.frag_size = fe_max_frag_size(ETH_DATA_LEN);
priv->rx_ring.rx_buf_size = fe_max_buf_size(priv->rx_ring.frag_size);
- priv->tx_ring.tx_ring_size = NUM_DMA_DESC;
+ priv->tx_ring.tx_ring_size = 4;
priv->rx_ring.rx_ring_size = NUM_DMA_DESC;
INIT_WORK(&priv->pending_work, fe_pending_work);
u64_stats_init(&priv->hw_stats->syncp);
Greats,
René
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
Ok, I took that "PMCR_P5/PORT 5 MAC Control Register" from
MT7621_ProgrammingGuide_GSW_v01.pdf. Couldnt find anything about P6, it's
quite confusing.
I totally understand that. Lack of complete documentation is an issue.
P6 = MAC6 in the documentation. AFAIK all the MACs do have the same register
layout. So MAC6 = PORT 6 and is connected to the first GMAC of the SOC.
PORT 5 = MAC5 and can be used as 2nd CPU port or connect to an external phy.
So MAC5, 2nd GMAC of the SOC and an external PHY share the same RGMII bus.
Depending on GPIO/PORT settings they are connected to the BUS. See
also mt7530.txt
kernel doc for more info.
1.
https://elixir.bootlin.com/linux/v5.6-rc1/source/drivers/staging/mt7621-dts/mt7621.dtsi#L489
-- ynezz
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[1]:
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/dsa/mt7530.txt#L38
Greats,
René
--- End Message ---
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
