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
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.
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.
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 ***