linux-kernel - Re: [PATCH 6.13 000/443] 6.13.3-rc1 review

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: <e7096ec2-68db-fc3e-9c48-f20d3e80df72@applied-asynchrony.com>
Date: Fri, 14 Feb 2025 09:32:06 +0100
From: Holger Hoffstätte <holger@...lied-asynchrony.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, stable@...r.kernel.org
Cc: patches@...ts.linux.dev, linux-kernel@...r.kernel.org,
 torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
 linux@...ck-us.net, shuah@...nel.org, patches@...nelci.org,
 lkft-triage@...ts.linaro.org, pavel@...x.de, jonathanh@...dia.com,
 f.fainelli@...il.com, sudipm.mukherjee@...il.com, srw@...dewatkins.net,
 rwarsow@....de, conor@...nel.org, hargar@...rosoft.com, broonie@...nel.org
Subject: Re: [PATCH 6.13 000/443] 6.13.3-rc1 review

On 2025-02-13 15:22, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.13.3 release.
> There are 443 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.

Builds & runs fine BUT fails to suspend to RAM 99.99% of the time (basically
one success but never again). Display powers down but fans stay on.

Tested on multiple systems, all x64. I first suspected amdgpu because why not :)
but it also fails on a system without amdgpu, so that's not it.

Reverting to 6.13.2 immediately fixes everything.

Common symptom on all machines seems to be

[  +0.000134] Disabling non-boot CPUs ...
[  +0.000072] Error taking CPU15 down: -16
[  +0.000002] Non-boot CPUs are not disabled

"Error taking down CPUX" is always the highest number of CPU, i.e.
15 on my 16-core Zen2 laptop, 3 on my 4-core Sandybridge etc.

I started to revert suspects but no luck so far:
- acpi parsing order
- amdgpu backlight quirks
- timers/hrtimers

Suggestions for other suspects are welcome.

-h