Bug 1857101

Summary: System wakes immediately after first Standby with kernel 5.7.x
Product: [Fedora] Fedora Reporter: Martin Wolf <mwolf>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 32CC: acaringi, airlied, bskeggs, hdegoede, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, lgoncalv, linville, masami256, mchehab, mjg59, steved
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: kernel-5.7.11-200.fc32 kernel-5.7.11-100.fc31 Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-08-02 01:23:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Martin Wolf 2020-07-15 06:47:31 UTC
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

Comment 1 Martin Wolf 2020-07-21 11:45:56 UTC
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"

Comment 2 Martin Wolf 2020-07-21 11:59:24 UTC
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.

Comment 3 Martin Wolf 2020-07-21 16:31:44 UTC
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(-)

Comment 4 Martin Wolf 2020-07-28 10:36:59 UTC
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?

Comment 5 Fedora Update System 2020-07-29 20:31:02 UTC
FEDORA-2020-0d6ef0188a has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d6ef0188a

Comment 6 Fedora Update System 2020-07-29 20:31:04 UTC
FEDORA-2020-253abe3b34 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-253abe3b34

Comment 7 Martin Wolf 2020-07-29 22:44:40 UTC
thank you!

Comment 8 Fedora Update System 2020-07-30 19:41:51 UTC
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.

Comment 9 Fedora Update System 2020-07-30 19:55:05 UTC
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.

Comment 10 Fedora Update System 2020-08-02 01:23:39 UTC
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.

Comment 11 Fedora Update System 2020-08-05 02:16:23 UTC
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.