On Fri, 9 Jan 2026 15:02:11 +0800 Tao Wang wrote:

after resume dev_watchdog() message:
"NETDEV WATCHDOG: CPU: x: transmit queue x timed out xx ms"

The trigging scenario is as follows:

When the TSO function sets tx_skbuff_dma[tx_q->cur_tx].last_segment = true

, and the last_segment value is not cleared in stmmac_free_tx_buffer after

 resume, restarting TSO transmission may incorrectly use

tx_q->tx_skbuff_dma[first_entry].last_segment = true for a new TSO packet.

When the tx queue has timed out, and the emac TX descriptor is as follows:
eth0: 221 [0x0000000876d10dd0]: 0x73660cbe 0x8 0x42 0xb04416a0
eth0: 222 [0x0000000876d10de0]: 0x77731d40 0x8 0x16a0 0x90000000

Descriptor 221 is the TSO header, and descriptor 222 is the TSO payload.

In the tdes3 (0xb04416a0), bit 29 (first descriptor) and bit 28

(last descriptor) of the TSO packet 221 DMA descriptor cannot both be

set to 1 simultaneously. Since descriptor 222 is the actual last

descriptor, failing to set it properly will cause the EMAC DMA to stop

and hang.

For some reason the reposted version of the patch has unnecessary empty
lines separating each line of this paragraph.

To solve the issue, set last_segment to false in stmmac_free_tx_buffer:
tx_q->tx_skbuff_dma[i].last_segment = false;
Set last_segment to false in stmmac_tso_xmit, and do not use the default
 value: tx_q->tx_skbuff_dma[first_entry].last_segment = false;
This will prevent similar issues from occurring in the future.

Please add a suitable Fixes tag, pointing at the commit which
introduced this incorrect behavior (either the commit which broke it or
the commit which added this code if it was always broken).
-- 
pw-bot: cr