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

[Maxime Chevallier]

Hi,

On 16/01/2026 19:08, Russell King (Oracle) wrote:
> On Fri, Jan 16, 2026 at 01:37:48PM +0000, Russell King (Oracle) wrote:
>> On Fri, Jan 16, 2026 at 12:50:35AM +0000, Russell King (Oracle) wrote:
>>> However, while this may explain the transmit slowdown because it's
>>> on the transmit side, it doesn't explain the receive problem.
>>
>> I'm bisecting to find the cause of the receive issue, but it's going to
>> take a long time (in the mean time, I can't do any mainline work.)
>>
>> So far, the range of good/bad has been narrowed down to 6.14 is good,
>> 1b98f357dadd ("Merge tag 'net-next-6.16' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next") is bad.
>>
>> 14 more iterations to go. Might be complete by Sunday. (Slowness in
>> building the more fully featured net-next I use primarily for build
>> testing, the slowness of the platform to reboot, and the need to
>> manually test each build.)
> 
> Well, that's been a waste of time today. While the next iteration was
> building, because it's been suspicious that each and every bisect
> point has failed so far, I decided to re-check 6.14, and that fails.
> So, it looks like this problem has existed for some considerable
> time. I don't have the compute power locally to bisect over a massive
> range of kernels, so I'm afraid stmmac receive is going to have to
> stay broken unless someone else can bisect (and find a "good" point
> in the git history.)
> 

To me RX looks OK, at least on the various devices I have that use
stmmac. It's fine on Cyclone V socfpga, and imx8mp. Maybe that's Jetson
specific ?

I've got pretty-much line rate with a basic 'iperf3 -c XX" and same with
'iperf3 -c XX -R". What commands are you running to check the issue ?

Are you still seeing the pause frames flood ?

Maxime