Re: stmmac: TX stalls with head OWN=1; requiring manual DMA kick (6.12.63)

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Thu, Mar 12, 2026 at 04:02:45PM +0200, Tomer Maimon wrote:
> Hi Andrew and Russell,
> 
> On Wed, 11 Mar 2026 at 22:52, Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> >
> > On Wed, Mar 11, 2026 at 08:46:04PM +0100, Andrew Lunn wrote:
> > > On Wed, Mar 11, 2026 at 08:34:36PM +0200, Tomer Maimon wrote:
> > > > Hi Giuseppe,
> > > >
> > > > On kernel 6.12.63 (GMAC, normal 16‑byte TX descriptors), we observe
> > > > brief TX stalls when sending small packets.
> > >
> > > You might want to look at Russell Kings patches from this week to
> > > rework the descriptor handling.
>
> Sorry, I mean 6.12 LTS.
> >
> > Yep.
> >
> > Not sure they'll materially affect any problem, because I try to avoid
> > functional changes in stuff like those.
> >
> > What's missing from the original report is a description of the
> > hardware. stmmac drives multiple different versions of the Synopsys
> > IP which have significant changes between them. Which platform glue
> > is being used, which core driver is being used (dwmac1000? dwmac4?
> > etc.)
> stmmac IP version is 3.73a
> The platform is glue is "snps,dwmac" and the core driver is "dwmac1000"

Thanks.

> > Also what isn't mentioned is whether this is a regression, or whether
> > it's something that has never worked. If it's a regression, which
> > kernel version previously worked?
> We ran the test with kernel 5.10 LTS, and it didn't work.

So it isn't a regression, but a persistent issue.

You mentioned in your original email:
> If the head descriptor still has OWN=1, issue a Transmit Poll Demand
> via stmmac_enable_dma_transmission().
> This immediately resumes the DMA and clears the stall.

This will be dwmac_lib.c::dwmac_enable_dma_transmission() which writes
to the transmit poll demand register. This write is prefixed on arm64
by a "dmb oshst" instruction which should ensure that previous writes
to the descriptors are visible to stmmac.

dwmac1000 doesn't have TSO and in any case the packet is too small for
TSO, so we can ignore stmmac_tso_xmit(). I'm also guessing your not
using xdp either, so we can rule out stmmac_xdp_xmit_zc() and
stmmac_xdp_xmit_xdpf().

So, we're looking at the normal path through stmmac_xmit().

The code at this point is:

        /* Set the OWN bit on the first descriptor now that all descriptors
         * for this skb are populated.
         */
        stmmac_set_tx_owner(priv, first_desc);

        netdev_tx_sent_queue(netdev_get_tx_queue(dev, queue), skb->len);

        stmmac_enable_dma_transmission(priv, priv->ioaddr, queue);

stmmac_set_tx_owner() will be calling norm_desc.c::ndesc_set_tx_owner()
which quite simply sets bit 31 in the descriptor via a
read-modify-write:

0000000000000000 <ndesc_set_tx_owner>:
   0:   b9400001        ldr     w1, [x0]
   4:   32010021        orr     w1, w1, #0x80000000
   8:   b9000001        str     w1, [x0]
   c:   d65f03c0        ret

and as I say, dwmac_enable_dma_transmission() includes the necessary
barrier to ensure that _that_ write should be visible to stmmac:

0000000000000120 <dwmac_enable_dma_transmission>:
 120:   52820082        mov     w2, #0x1004                     // #4100
 124:   0b012041        add     w1, w2, w1, lsl #8
 128:   8b214001        add     x1, x0, w1, uxtw
 12c:   d50332bf        dmb     oshst
 130:   52800020        mov     w0, #0x1                        // #1
 134:   b9000020        str     w0, [x1]
 138:   d65f03c0        ret

However, I'm wondering if we have an issue with the descriptor writes
becoming visible in the wrong order. Please can you try adding a
dma_wmb() immediately before stmmac_set_tx_owner() in stmmac_xmit()
to ensure that all previous descriptor settings are fully visible
before we update the OWN bit on the first descriptor and make that
update visible?

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!