Bug 1857101

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.