On 01/11/2026 13:22, Greg Kroah-Hartman wrote:

On Sat, Oct 31, 2026 at 02:41:43PM +0000, Jon Hunter wrote:

...

Hi Greg,

On 31/10/2026 09:26, Jon Hunter wrote:

...

...

On 31/10/2026 09:24, Jon Hunter wrote:

...

On Thu, 29 Oct 2026 08:33:04 +0100, Greg Kroah-Hartman wrote:

...

This is the start of the stable review cycle for the 6.1.191 release. There are 1879 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sat, 31 Oct 2026 07:28:30 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.191-rc2... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y and the diffstat can be found below.

thanks,

greg k-h

Failures detected for Tegra ...

Test results for stable-v6.1: builds: 9 pass, 0 fail boots: 28 pass, 4 fail tests: 83 pass, 7 fail

Linux version: 6.1.191-rc2-g3b00df762ebc Boards tested: tegra20-ventana tegra30-cardhu-a04 tegra124-jetson-tk1 tegra210-p2371-2180 tegra210-p3450-0000 tegra186-p2771-0000 tegra186-p3509-0000+p3636-0001 tegra194-p2972-0000 tegra194-p3509-0000+p3668-0000

Boot failures: tegra186-p2771-0000, tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000

Test failures: tegra124-jetson-tk1: pm-system-suspend.sh tegra20-ventana: pm-system-suspend.sh tegra30-cardhu-a04: pm-system-suspend.sh

I am looking into the above boot and suspend issues and will let you know what I find.

Bisecting is pointing to the below commit and reverting it fixes the above issues ...

# first bad commit: [26c5e136ba4e94ad708333c9bd34039a1de397b0] net: stmmac: protect updates of 64-bit statistics counters

Thanks, I've reverted that one now.

Thanks. It turns out that there are two issue here; one causing the above boot failures and one causing the above suspend failures. I had thought it was the same issue but now I see that suspend is still failing.

To fix the suspend issue I also needed to revert ...

commit 3d64d18bdd1b2a6bd4af1176a596736b233606be Author: Rob Clark robdclark@chromium.org Date: Mon Aug 7 10:11:40 2023 -0700

interconnect: Fix locking for runpm vs reclaim

The above commit is dependent upon the following and so I had to revert the following too ...

commit da051a8d3d67bb039a26bac02f439c316ac0151a Author: Mike Tipton quic_mdtipton@quicinc.com Date: Tue Mar 5 14:56:52 2024 -0800

interconnect: Don't access req_list while it's being manipulated

So to fix all issues, I needed to revert 3 commits in total (commit 26c5e136ba4e94ad708333c9bd34039a1de397b0 plus the above 2 commits).

Jon

Bisecting is pointing to the below commit and reverting it fixes the above issues ...

# first bad commit: [26c5e136ba4e94ad708333c9bd34039a1de397b0] net: stmmac: protect updates of 64-bit statistics counters

Thanks for bisecting. 6.1 is missing a prerequisite for that backport.

38cc3c6dcc09 ("net: stmmac: protect updates of 64-bit statistics counters") allocates priv->xstats.pcpu_stats in stmmac_dvr_probe(). 6.1 does not have 2eb85b750512 ("net: stmmac: don't clear network statistics in .ndo_open()"), so the memset() of priv->xstats in __stmmac_open() zeroes that pointer on every ifup, and the first DMA interrupt on a dwmac4 device (Tegra186/194 EQOS) dereferences a NULL percpu pointer.

Greg has queued a revert of the backport for 6.1, so this goes away in the next 6.1 release. 38cc3c6dcc09 can come back to 6.1 later together with 2eb85b750512.

Could you test if adding in 2eb85b750512 fixes the issue?

...

Could you test if adding in 2eb85b750512 fixes the issue?

I confirmed that that does fix it.

Thanks for testing. Queued for 6.1: 2eb85b750512 ("net: stmmac: don't clear network statistics in .ndo_open()") followed by 38cc3c6dcc09 ("net: stmmac: protect updates of 64-bit statistics counters") again.