linux-kernel - Re: [PATCH net v2] net: stmmac: fix transmit queue timed out after resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6a946edc-297e-469a-8d91-80430d88f3e5@bootlin.com>
Date: Thu, 15 Jan 2026 22:04:39 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>,
 Tao Wang <tao03.wang@...izon.auto>
Cc: alexandre.torgue@...s.st.com, andrew+netdev@...n.ch, davem@...emloft.net,
 edumazet@...gle.com, horms@...nel.org, kuba@...nel.org,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 mcoquelin.stm32@...il.com, netdev@...r.kernel.org, pabeni@...hat.com
Subject: Re: [PATCH net v2] net: stmmac: fix transmit queue timed out after
 resume

Hi,

> 
> I've just run iperf3 in both directions with the kernel I had on the
> board (based on 6.18.0-rc7-net-next+), and stmmac really isn't looking
> particularly great - by that I mean, iperf3 *failed* spectacularly.
> 
> First, running in normal mode (stmmac transmitting, x86 receiving)
> it's only capable of 210Mbps, which is nowhere near line rate.
> 
> However, when running iperf3 in reverse mode, it filled the stmmac's
> receive queue, which then started spewing PAUSE frames at a rate of
> knots, flooding the network, and causing the entire network to stop.
> It never recovered without rebooting.
> 
> Trying again on 6.19.0-rc4-net-next+,
> 
> stmmac transmitting shows the same dire performance:
> 
> [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
> [  5]   0.00-1.00   sec  24.2 MBytes   203 Mbits/sec    0    230 KBytes
> [  5]   1.00-2.00   sec  25.5 MBytes   214 Mbits/sec    0    230 KBytes
> [  5]   2.00-3.00   sec  25.0 MBytes   210 Mbits/sec    0    230 KBytes
> [  5]   3.00-4.00   sec  25.5 MBytes   214 Mbits/sec    0    230 KBytes
> [  5]   4.00-5.00   sec  25.1 MBytes   211 Mbits/sec    0    230 KBytes
> [  5]   5.00-6.00   sec  25.1 MBytes   211 Mbits/sec    0    230 KBytes
> [  5]   6.00-7.00   sec  25.7 MBytes   215 Mbits/sec    0    230 KBytes
> [  5]   7.00-8.00   sec  25.2 MBytes   212 Mbits/sec    0    230 KBytes
> [  5]   8.00-9.00   sec  25.3 MBytes   212 Mbits/sec    0    346 KBytes
> [  5]   9.00-10.00  sec  25.4 MBytes   213 Mbits/sec    0    346 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate         Retr
> [  5]   0.00-10.00  sec   252 MBytes   211 Mbits/sec    0             sender
> [  5]   0.00-10.02  sec   250 MBytes   210 Mbits/sec                  receiver
> 
> stmmac receiving shows the same problem:
> 
> [ ID] Interval           Transfer     Bitrate
> [  5]   0.00-1.00   sec  64.1 MBytes   537 Mbits/sec
> [  5]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec
> [  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec
> [  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec
> [  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec
> [  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec
> [  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec
> [  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec
> [  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec
> ^C[  5]   9.00-9.43   sec  0.00 Bytes  0.00 bits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate
> [  5]   0.00-9.43   sec  0.00 Bytes  0.00 bits/sec                  sender
> [  5]   0.00-9.43   sec  64.1 MBytes  57.0 Mbits/sec                  receiver
> iperf3: interrupt - the client has terminated

Heh, I was able to reproduce something similar on imx8mp, that has an
imx-dwmac (dwmac 4/5 according to dmesg) :

DUT to x86

Connecting to host 192.168.2.1, port 5201
[  5] local 192.168.2.13 port 54744 connected to 192.168.2.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  0.00 Bytes  0.00 bits/sec    2   1.41 KBytes
[  5]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes

x86 to DUT :

Reverse mode, remote host 192.168.2.1 is sending
[  5] local 192.168.2.13 port 47050 connected to 192.168.2.1 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   112 MBytes   935 Mbits/sec
[  5]   1.00-2.00   sec   112 MBytes   936 Mbits/sec
[  5]   2.00-3.00   sec   112 MBytes   936 Mbits/sec

Nothing as bas as what you face, but there's defintely something going
on there. "good" news is that it worked in v6.19-rc1, I have a bisect
ongoing.

I'll update once I have homed-in on something.

Maxime