Bug 215606

Summary:	No sound after suspend, possible regression
Product:	Drivers	Reporter:	Stephane Travostino (steph)
Component:	Sound(ALSA)	Assignee:	Jaroslav Kysela (perex)
Status:	RESOLVED DUPLICATE
Severity:	normal
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	5.16 and later	Subsystem:
Regression:	Yes	Bisected commit-id:
Attachments:	alsactl task failing to freeze on suspend

Description Stephane Travostino 2022-02-14 15:34:59 UTC

Created attachment 300452 [details]
alsactl task failing to freeze on suspend

I (and other pipewire users) are having sound issues after suspend, and I suspect a possible kernel or driver issue might be the culprit. I'm running Fedora 35 and using an external USB interface MOTU M4 for audio playback.

Audio is fine on first boot, but after a suspend/resume cycle (not 100% reproducible) pipewire starts misbehaving, gets stuck in uninterruptible sleep state and sound is broken until reboot.

I've started noticing the problem with Fedora's 5.16.7, same issue on the latest _vanilla_ kernel 5.17.0-0.rc3.20220211gitf1baf68e1383, but everything seems fine on 5.15.16 and earlier kernels.

Not sure how useful it is, but one time during a manual suspend to try and reproduce the bug, I got a kernel backtrace about an alsa task that didn't want to freeze during suspend (attached), and after resume audio was broken.

Related pipewire issue: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2001

Comment 1 Stephane Travostino 2022-02-18 12:12:48 UTC

Bug is present on v5.16.1 as well, so it must have been introduced between v5.15.16 and v5.16.1 — I have started a bisect process to figure out the culprit.

In any case, on some? buggy kernels, I've seen the following error upon resume from suspend:

snd-usb-audio 1-3.4.2:1.0: reset_resume error -22

I'll update this ticket if my bisect is successful.

Comment 2 Stephane Travostino 2022-02-18 19:21:14 UTC

Bisect was successful:

b96681bd58276e1c7ca4ca37bbaab9f8f1738d61 is the first bad commit
commit b96681bd58276e1c7ca4ca37bbaab9f8f1738d61
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Oct 14 15:06:36 2021 +0200

    ALSA: usb-audio: Initialize every feature unit once at probe time
    
    So far we used to read the current value of the mixer element
    dynamically at the first access, and the error from a GET_CUR message
    is treated as a fatal error (unless QUIRK_IGNORE_CTL_ERROR is set).
    It's rather inconvenient, as most of GET_CUR errors are no fatal, and
    we can continue operation with assumption of some fixed value.
    
    This patch makes the USB-audio driver to change the behavior at probe
    time; now it tries to initialize the current value of each mixer
    element that is built from a feature unit (those for typically for
    mixer volumes and switches).  When a read failure happens, it tries to
    set the known minimum value.  After that point, a cached value is used
    always, hence we won't hit GET_CUR message error any longer.
    
    The error from GET_CUR message is still shown as a warning normally,
    but only once at the probe time, and it'll keep operating.  If the
    message is confirmed to be harmless, it can be shut up by
    QUIRK_IGNORE_CTL_ERROR quirk flag, too.
    
    Tested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20211014130636.17860-4-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

--

How I reproduce the issue:

1. Put machine to sleep
2. Resume. Buggy commits will print "snd-usb-audio 1-3.4.2:1.0: reset_resume error -22" to dmesg. Audio at this point usually works
3. Put machine to sleep again
4. Wait 5 or 10 minutes (Somehow necessary)
5. Audio's broken, pipewire's stuck, sysrq is required to restart the machine.

--

Based on my understanding, any Linux kernel past v5.16-rc1 exhibit the issue.

Comment 3 Stephane Travostino 2022-02-19 22:43:58 UTC

Looks like this is a duplicate of https://bugzilla.kernel.org/show_bug.cgi?id=215561

*** This bug has been marked as a duplicate of bug 215561 ***