netdev - 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: <aWp-lDunV9URYNRL@shell.armlinux.org.uk>
Date: Fri, 16 Jan 2026 18:08:20 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: Tao Wang <tao03.wang@...izon.auto>, 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

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

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