[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5b51c818-86c0-bc91-cb96-90cd63ca394f@applied-asynchrony.com>
Date: Fri, 14 Feb 2025 10:06:02 +0100
From: Holger Hoffstätte <holger@...lied-asynchrony.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: stable@...r.kernel.org, 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-14 09:42, Greg Kroah-Hartman wrote:
> On Fri, Feb 14, 2025 at 09:32:06AM +0100, Holger Hoffstätte wrote:
>> 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.
>
> Can you run 'git bisect' to try to find the offending change?
Can do later today but this is going to take a while - slow HW. :(
-h
Powered by blists - more mailing lists