When I upgraded to kernel 5.7.6 and ongoing I noticed that my System immediately wakes up after sending it to standby. When I send it back to standby it stays that way. Till Kernel 5.6.19 this did NOT occur. I already disabled all wakeup triggers except ps2k because of standby issues with my mainboard (ASUS z97-A USB3.1) so the problem has to be somewhere else this time. cat /proc/acpi/wakeup Device S-state Status Sysfs node PEG0 S4 *disabled pci:0000:00:01.0 PEGP S4 *disabled pci:0000:01:00.0 PEG1 S4 *disabled PEGP S4 *disabled PEG2 S4 *disabled PEGP S4 *disabled UAR1 S4 *disabled PS2K S4 *enabled pnp:00:06 *disabled serio:serio0 PS2M S4 *disabled RP01 S4 *disabled pci:0000:00:1c.0 PXSX S4 *disabled RP02 S4 *disabled PXSX S4 *disabled RP03 S4 *disabled PXSX S4 *disabled RP05 S4 *disabled PXSX S4 *disabled RP06 S4 *disabled PXSX S4 *disabled RP07 S4 *disabled pci:0000:00:1c.6 PXSX S4 *disabled pci:0000:05:00.0 RP08 S4 *disabled PXSX S4 *disabled RP04 S4 *disabled pci:0000:00:1c.3 PXSX S4 *disabled pci:0000:03:00.0 GLAN S4 *disabled pci:0000:00:19.0 EHC1 S4 *disabled pci:0000:00:1d.0 EHC2 S4 *disabled pci:0000:00:1a.0 XHC S4 *disabled pci:0000:00:14.0 HDEF S4 *disabled pci:0000:00:1b.0
Sorry for being silent for a week. I was busy but today I had some time to dig a little deeper ... I tested a few Kernel Versions and I found out, that the problem started to occur with "kernel-5.7.0-0.rc2.20200422git18bf34080c4c.1.fc33" and was not present in "kernel-5.7.0-0.rc1.20200416git9786cab67457.1.fc33"
The problem also occurs in "kernel-5.7.0-0.rc2.1.fc33" so it started between rc2 and "kernel-5.7.0-0.rc1.20200416git9786cab67457.1.fc33" What can I do now? I really have no clue how to properly bisect a fedora kernel. The scripts I found are dependent on python2.x Maybe you can give me some assistance here please.
I bisected the Kernel and this is the faulty commit: c4c8dd6ef807663e42a5f04ea77cd62029eb99fa is the first bad commit commit c4c8dd6ef807663e42a5f04ea77cd62029eb99fa Author: Takashi Iwai <tiwai> Date: Mon Apr 13 10:20:33 2020 +0200 ALSA: hda: Skip controller resume if not needed The HD-audio controller does system-suspend and resume operations by directly calling its helpers __azx_runtime_suspend() and __azx_runtime_resume(). However, in general, we don't have to resume always the device fully at the system resume; typically, if a device has been runtime-suspended, we can leave it to runtime resume. Usually for achieving this, the driver would call pm_runtime_force_suspend() and pm_runtime_force_resume() pairs in the system suspend and resume ops. Unfortunately, this doesn't work for the resume path in our case. For handling the jack detection at the system resume, a child codec device may need the (literally) forcibly resume even if it's been runtime-suspended, and for that, the controller device must be also resumed even if it's been suspended. This patch is an attempt to improve the situation. It replaces the direct __azx_runtime_suspend()/_resume() calls with with pm_runtime_force_suspend() and pm_runtime_force_resume() with a slight trick as we've done for the codec side. More exactly: - azx_has_pm_runtime() check is dropped from azx_runtime_suspend() and azx_runtime_resume(), so that it can be properly executed from the system-suspend/resume path - The WAKEEN handling depends on the card's power state now; it's set and cleared only for the runtime-suspend - azx_resume() checks whether any codec may need the forcible resume beforehand. If the forcible resume is required, it does temporary PM refcount up/down for actually triggering the runtime resume. - A new helper function, hda_codec_need_resume(), is introduced for checking whether the codec needs a forcible runtime-resume, and the existing code is rewritten with that. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043 Link: https://lore.kernel.org/r/20200413082034.25166-6-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai> include/sound/hda_codec.h | 5 +++++ sound/pci/hda/hda_codec.c | 2 +- sound/pci/hda/hda_intel.c | 38 +++++++++++++++++++++++++++----------- 3 files changed, 33 insertions(+), 12 deletions(-)
I also reported it on bugzilla.kernel.org and we were able to find a fix: https://bugzilla.kernel.org/show_bug.cgi?id=208649#c47 can you please put it in the fedora kernel, till it reaches mainline?
FEDORA-2020-0d6ef0188a has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d6ef0188a
FEDORA-2020-253abe3b34 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-253abe3b34
thank you!
FEDORA-2020-0d6ef0188a has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-0d6ef0188a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d6ef0188a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-253abe3b34 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-253abe3b34` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-253abe3b34 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-253abe3b34 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-0d6ef0188a has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.