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

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

[Tomer Maimon]

Hi Giuseppe,

On kernel 6.12.63 (GMAC, normal 16‑byte TX descriptors), we observe
brief TX stalls when sending small packets.

During these pauses, when stmmac_tx_clean() runs, the head descriptor
(dirty_tx) consistently still has OWN=1 across multiple NAPI polls.
Descriptor programming in xmit() looks correct (OWN=1, FD/LD=1, CIC=2,
length ≈ 60–110 bytes), but reclamation does not proceed until a later
event (typically the next TX).

Reading DMA_STATUS during the stall shows the Transmit Process State
(TS) remains active (TS = 6), so the TX DMA engine appears to be
running, but it is not fetching the head descriptor, and the OWN bit
remains set until something nudges the engine.

As a work‑around, we added the following logic inside stmmac_tx_clean():

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.

We would appreciate your feedback on the following questions:

Are you familiar with this behavior in the stmmac TX path (head OWN=1
in tx_clean despite TS being active)?
What conditions could cause the TX DMA not to fetch new descriptors
even when TS=6?
Is this work‑around acceptable, or would you recommend a different
trigger/condition for issuing Transmit Poll Demand?

Thank you,

Tomer

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

[Andrew Lunn]

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.

Also, please don't report problems on dead kernels. 6.12.76 is the
current version for the 6.12 LTS. There is a small chance your problem
has already been fixed, and you are wasting everybody's time.

       Andrew

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

[Russell King (Oracle)]

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.
> 
> Also, please don't report problems on dead kernels. 6.12.76 is the
> current version for the 6.12 LTS. There is a small chance your problem
> has already been fixed, and you are wasting everybody's time.

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.)

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?

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

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

[Tomer Maimon]

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.
Could you point me to Russell Kings patches?
> >
> > Also, please don't report problems on dead kernels. 6.12.76 is the
> > current version for the 6.12 LTS. There is a small chance your problem
> > has already been fixed, and you are wasting everybody's time.
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"
>
> 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.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Thanks,

Tomer

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

[Tomer Maimon]

Hi All,

Appreciate your comments on the reply that I sent a few days ago

Thanks,

Tomer

On Thu, 12 Mar 2026 at 16:02, Tomer Maimon <tmaimon77@gmail.com> 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.
> Could you point me to Russell Kings patches?
> > >
> > > Also, please don't report problems on dead kernels. 6.12.76 is the
> > > current version for the 6.12 LTS. There is a small chance your problem
> > > has already been fixed, and you are wasting everybody's time.
> 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"
> >
> > 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.
> >
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
>
> Thanks,
>
> Tomer

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

[Russell King (Oracle)]

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!