Bug 1857101 - System wakes immediately after first Standby with kernel 5.7.x
Summary: System wakes immediately after first Standby with kernel 5.7.x
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 32
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-07-15 06:47 UTC by Martin Wolf
Modified: 2020-08-05 02:16 UTC (History)
19 users (show)

Fixed In Version: kernel-5.7.11-200.fc32 kernel-5.7.11-100.fc31
Doc Type: ---
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-08-02 01:23:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.