From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Sam Edwards <cfsworks@gmail.com>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Maxime Chevallier <maxime.chevallier@bootlin.com>,
Ovidiu Panait <ovidiu.panait.rb@renesas.com>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
Baruch Siach <baruch@tkos.co.il>,
Serge Semin <fancer.lancer@gmail.com>,
Giuseppe Cavallaro <peppe.cavallaro@st.com>,
netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v4 0/2] stmmac crash/stall fixes when under memory pressure
Date: Fri, 10 Apr 2026 13:23:17 +0100 [thread overview]
Message-ID: <adjrtRSepmac2hpN@shell.armlinux.org.uk> (raw)
In-Reply-To: <CAH5Ym4g3pbU_bWzMwJMdhEFv4K2sp3pty3g04=0=9Z80_LzW1w@mail.gmail.com>
On Thu, Apr 02, 2026 at 10:39:32AM -0700, Sam Edwards wrote:
> On Thu, Apr 2, 2026 at 10:16 AM Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> > I've tested this on my Jetson Xavier platform. One of the issues I've
> > had is that running iperf3 results in the receive side stalling because
> > it runs out of descriptors. However, despite the receive ring
> > eventually being re-filled and the hardware appropriately prodded, it
> > steadfastly refuses to restart, despite the descriptors having been
> > updated.
>
> Hi Russell,
>
> Just to make sure I understand correctly: before my patches, you've
> been observing this problem on Xavier for a while (no interrupts, ring
> goes dry); with my patches, the ring is refilled, but the dwmac5
> doesn't resume DMA. (Ah, just saw your follow-up email.)
>
> > Any ideas?
>
> Off the top of my head, my hypothesis is that dwmac5 has an additional
> tripwire when the receive DMA is exhausted, and the
> stmmac_set_rx_tail_ptr()/stmmac_enable_dma_reception() at the end of
> stmmac_rx_refill() aren't sufficient to wake it back up.
>
> I think this is new to dwmac5, because my RK3588 (dwmac4.20 iirc)
> happily resumes after the same condition.
>
> You gave a lot of info; thanks! I'll try to scrape up some
> documentation on dwmac5 to see if there's something more
> stmmac_rx_refill() ought to be doing. I think I have a Xavier NX
> around here somewhere, I'll see if I can repro the problem.
I've added dma_rmb() into dwmac4_wrback_get_tx_status() and
dwmac4_wrback_get_rx_status(), and with that I've had an iperf3
instance finally complete... but only once:
root@tegra-ubuntu:~# iperf3 -c 192.168.248.1 -R
Connecting to host 192.168.248.1, port 5201
Reverse mode, remote host 192.168.248.1 is sending
[ 5] local 192.168.248.174 port 42232 connected to 192.168.248.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 50.8 MBytes 426 Mbits/sec
[ 5] 1.00-2.00 sec 54.9 MBytes 460 Mbits/sec
[ 5] 2.00-3.00 sec 54.0 MBytes 453 Mbits/sec
[ 5] 3.00-4.00 sec 53.8 MBytes 452 Mbits/sec
[ 5] 4.00-5.00 sec 52.4 MBytes 438 Mbits/sec
[ 5] 5.00-6.00 sec 54.3 MBytes 455 Mbits/sec
[ 5] 6.00-7.00 sec 53.7 MBytes 452 Mbits/sec
[ 5] 7.00-8.00 sec 52.8 MBytes 443 Mbits/sec
[ 5] 8.00-9.00 sec 53.7 MBytes 451 Mbits/sec
[ 5] 9.00-10.00 sec 54.3 MBytes 455 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 537 MBytes 450 Mbits/sec 13 sender
[ 5] 0.00-10.00 sec 535 MBytes 448 Mbits/sec receiver
iperf Done.
So, it seems better, but not completely solved.
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index 2994df41ec2c..119f31c94b61 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -17,10 +17,12 @@ static int dwmac4_wrback_get_tx_status(struct stmmac_extra_stats *x,
struct dma_desc *p,
void __iomem *ioaddr)
{
- u32 tdes3 = le32_to_cpu(p->des3);
+ u32 tdes3;
int ret = tx_done;
/* Get tx owner first */
+ dma_rmb();
+ tdes3 = le32_to_cpu(p->des3);
if (unlikely(tdes3 & TDES3_OWN))
return tx_dma_own;
@@ -70,12 +72,12 @@ static int dwmac4_wrback_get_tx_status(struct stmmac_extra_stats *x,
static int dwmac4_wrback_get_rx_status(struct stmmac_extra_stats *x,
struct dma_desc *p)
{
- u32 rdes1 = le32_to_cpu(p->des1);
- u32 rdes2 = le32_to_cpu(p->des2);
- u32 rdes3 = le32_to_cpu(p->des3);
+ u32 rdes1, rdes2, rdes3;
int message_type;
int ret = good_frame;
+ dma_rmb();
+ rdes3 = le32_to_cpu(p->des3);
if (unlikely(rdes3 & RDES3_OWN))
return dma_own;
@@ -107,6 +109,7 @@ static int dwmac4_wrback_get_rx_status(struct stmmac_extra_stats *x,
message_type = FIELD_GET(RDES1_PTP_MSG_TYPE_MASK, rdes1);
+ rdes1 = le32_to_cpu(p->des1);
if (rdes1 & RDES1_IP_HDR_ERROR) {
x->ip_hdr_err++;
ret |= csum_none;
@@ -152,6 +155,7 @@ static int dwmac4_wrback_get_rx_status(struct stmmac_extra_stats *x,
if (rdes1 & RDES1_TIMESTAMP_DROPPED)
x->timestamp_dropped++;
+ rdes2 = le32_to_cpu(p->des2);
if (unlikely(rdes2 & RDES2_SA_FILTER_FAIL)) {
x->sa_rx_filter_fail++;
ret = discard_frame;
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2026-04-10 12:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-01 4:19 [PATCH net v4 0/2] stmmac crash/stall fixes when under memory pressure Sam Edwards
2026-04-01 4:19 ` [PATCH net v4 1/2] net: stmmac: Prevent NULL deref when RX memory exhausted Sam Edwards
2026-04-01 4:19 ` [PATCH net v4 2/2] net: stmmac: Prevent indefinite RX stall on buffer exhaustion Sam Edwards
2026-04-02 15:05 ` [PATCH net v4 0/2] stmmac crash/stall fixes when under memory pressure Jakub Kicinski
2026-04-02 16:53 ` Sam Edwards
2026-04-03 0:40 ` Jakub Kicinski
2026-04-02 17:16 ` Russell King (Oracle)
2026-04-02 17:26 ` Russell King (Oracle)
2026-04-02 17:39 ` Sam Edwards
2026-04-10 12:23 ` Russell King (Oracle) [this message]
2026-04-03 6:14 ` Maxime Chevallier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=adjrtRSepmac2hpN@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=baruch@tkos.co.il \
--cc=cfsworks@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fancer.lancer@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=maxime.chevallier@bootlin.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=ovidiu.panait.rb@renesas.com \
--cc=pabeni@redhat.com \
--cc=peppe.cavallaro@st.com \
--cc=vladimir.oltean@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox