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:

quoted

On Fri, Jan 16, 2026 at 12:50:35AM +0000, Russell King (Oracle) wrote:

quoted

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