I'm seeing multiple reports of suspend and resume being broken in 6.10 kernels on Lenovo platforms - P16v G1 AMD, Z13 G2, T14 G4 AMD. If the system is suspended and the power unplugged (or plugged) the system will wake up. I was able to reproduce the problem on the P16v and did a kernel bisect. I confirmed the commit that introduces the issue is: 166a490f59ac10340ee5330e51c15188ce2a7f8f is the first bad commit commit 166a490f59ac10340ee5330e51c15188ce2a7f8f (HEAD) Author: Baochen Qiang <quic_bqiang@quicinc.com> Date: Mon Apr 8 17:41:50 2024 +0300 wifi: ath11k: support hibernation I haven't been able to drill down into the details of the commit as it's outside my expertise. Please can I get help fixing this issue - it is impacting many users on multiple different platforms. I'll note that suspend and resume functionality is more important than hibernation to the majority of the users. I'm happy to help test hibernation fixes in the longer term but suggest this patch gets reverted until a full fix has been proven. Thanks! Mark
Mark, did you test that reverting that commit on top v6.10 fixes the issue?
Created attachment 306780 [details] kernel log when system wakes from power disconnect
Hi Kalle, I hadn't done that - but I have now. I tested a 6.10 build with git revert on that one commit, and the system stays suspended when power is connected/disconnected. Let me know if there are any logs that would be useful. I haven't stress tested it - but everything looks good. I did also attach a kernel log from when I was running a kernel built right after 166a490f59ac was added (broken condition). It's not very interesting, but figured it should be added in case useful. Mark
Hi, I can confirm that this issue affects my Lenovo Thinkpad Z13 as well. Also can confirm that reverting that patch from 6.10 solves the problem. If a fix isn't found quickly, I suggest to either revert that patch upstream and/or in the distro kernels so that users aren't left with a buggy system while Qualcomm investigates this issue. Note that this isn't the first time I've seen this problem, it also appeared when I first bought this laptop in 2022 but was eventually fixed. Would it be possible to set up some sort of process to avoid regressions like this?
> If a fix isn't found quickly, I suggest to either revert that patch upstream > and/or in the distro kernels so that users aren't left with a buggy system > while Qualcomm investigates this issue. I am preparing to send a revert for v6.11. > Note that this isn't the first time I've seen this problem, it also appeared > when I first bought this laptop in 2022 but was eventually fixed. Would it be > possible to set up some sort of process to avoid regressions like this? I do run regression tests with ath11k but this seems to be a Lenovo specific problem and I don't have any Lenovo hardware with WCN6855.
As a side note, it seems that without reverting the aforementioned patch, the issue still occurs even when the wifi adapter is disabled. This makes me think that there may be another bug: the wifi adapter isn't correctly powered down even when it is disabled, otherwise how would it be able to wake up the laptop?
(In reply to Timur Kristóf from comment #4) > Hi, > > I can confirm that this issue affects my Lenovo Thinkpad Z13 as well. Also > can confirm that reverting that patch from 6.10 solves the problem. > > If a fix isn't found quickly, I suggest to either revert that patch upstream > and/or in the distro kernels so that users aren't left with a buggy system > while Qualcomm investigates this issue. > > Note that this isn't the first time I've seen this problem, it also appeared > when I first bought this laptop in 2022 but was eventually fixed. Would it > be possible to set up some sort of process to avoid regressions like this? I have a Z13 as well but not able to reproduce this issue with that commit kept. this makes me want to check the difference in BIOS: My Z13 has a BIOS of version N3GET63W(1.63) and the BIOS data says 2023-08-24. could you share your machine's BIOS version?
(In reply to Timur Kristóf from comment #6) > As a side note, it seems that without reverting the aforementioned patch, > the issue still occurs even when the wifi adapter is disabled. This makes me > think that there may be another bug: the wifi adapter isn't correctly > powered down even when it is disabled, otherwise how would it be able to > wake up the laptop? what do you mean by 'disable'? is it a 'ifconfig <inf> down' or a complete ath11k driver unload/blacklisted?
The revert is applied for v6.11: https://git.kernel.org/ath/ath/c/2f833e8948d6