If I use the microphone, then suspend and wake up again, I get the error
snd-usb-audio 1-5:1.0: reset_resume error -22
Aftewards, audio stops working completely. Both pipewire and pulseaudio (tried both; not at the same time) freeze.
rmmod -f snd_usb_audio
and replugging the microphone, audio works again.
Here is the relevant log:
[ 157.791937] usbcore: deregistering interface driver snd-usb-audio
[ 228.517855] usb 1-5: USB disconnect, device number 2
[ 236.464334] usb 1-5: new high-speed USB device number 3 using xhci_hcd
[ 236.798863] usb 1-5: New USB device found, idVendor=0d8c, idProduct=0171, bcdDevice= 1.04
[ 236.798867] usb 1-5: New USB device strings: Mfr=3, Product=1, SerialNumber=0
[ 236.798869] usb 1-5: Product: USB 2.0 HD Audio
[ 236.798871] usb 1-5: Manufacturer: C-Media Electronics Inc.
[ 236.826966] input: C-Media Electronics Inc. USB 2.0 HD Audio Consumer Control as /devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-5/1-5:1.3/0003:0D8C:0171.000B/input/input40
[ 236.878380] input: C-Media Electronics Inc. USB 2.0 HD Audio as /devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-5/1-5:1.3/0003:0D8C:0171.000B/input/input41
[ 236.878447] hid-generic 0003:0D8C:0171.000B: input,hiddev96,hidraw2: USB HID v1.11 Device [C-Media Electronics Inc. USB 2.0 HD Audio] on usb-0000:02:00.0-5/input3
[ 242.306593] usbcore: registered new interface driver snd-usb-audio
I'm running Arch Linux (5.16.4.arch1-1). The linux-lts kernel (5.15.18-1) works fine.
Other uses report the same error: https://bbs.archlinux.org/viewtopic.php?id=273469
To be explicit, this bug started on Arch at the release of 5.16 and has existed in all of 5.16.1, .2, .3, .4, and .5 releases so far. I get this bug every time if I suspend while my dock is plugged in.
The bug has also been reported on NixOS: https://github.com/NixOS/nixpkgs/issues/157755. Note, still occurs on 5.16.6 and .7.
Could you perform git-bisect and identify the culprit commit?
@Takashi, I can't really try that. Note that when this fault occurs my machine becomes unusable and also will not reboot. I have to hard reset it via the power switch. I see this with my dock but I just removed that and replicated it with nothing plugged in to my XPS 13 laptop except a direct USB headset. Set sound output to that and then suspend. When resuming, sound will lock up. Still fails on 5.16.8, works fine on all of 5.15 -> 5.15.22 and before.
If 5.15.22 works and 5.16 doesn't, it's likely not about the sound driver but rather in a lower layer. USB-audio driver code of 5.15.22 is almost identical with 5.16.x.
@Takashi I can try to bisect this weekend. Though I have not run a self-compiled kernel on my desktop, so I have to figure that out first.
@Mark, for me force reloading the module (see https://bbs.archlinux.org/viewtopic.php?pid=2018644#p2018644) works. Afterwards I can also reboot cleanly.
@Takashi the first bad commit is b96681bd58276e1c7ca4ca37bbaab9f8f1738d61
# good: [56d33754481fe0dc7436dc4ee4fbd44b3039361d] Merge tag 'drm-next-2021-11-03' of git://anongit.freedesktop.org/drm/drm
git bisect good 56d33754481fe0dc7436dc4ee4fbd44b3039361d
# bad: [25edbc383b72c2364c7b339245c1c5db84e615e1] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
git bisect bad 25edbc383b72c2364c7b339245c1c5db84e615e1
# good: [86e2d14b6d1a68941b6c0ef39502ec1433b680cb] ASoC: topology: Add header payload_size verification
git bisect good 86e2d14b6d1a68941b6c0ef39502ec1433b680cb
# good: [dcd68326d29b62f3039e4f4d23d3e38f24d37360] Merge tag 'devicetree-for-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
git bisect good dcd68326d29b62f3039e4f4d23d3e38f24d37360
# good: [840f4ed2d47b525c0bccc10e4aeaf7a4beeffc67] IB/qib: Rebranding of qib driver to Cornelis Networks
git bisect good 840f4ed2d47b525c0bccc10e4aeaf7a4beeffc67
# bad: [b97053df0f04747c3c1e021ecbe99db675342954] ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
git bisect bad b97053df0f04747c3c1e021ecbe99db675342954
# good: [6f00d1651b32f7f2951d9f299eb79b03c10186e3] Merge branch 'for-linus' into for-next
git bisect good 6f00d1651b32f7f2951d9f299eb79b03c10186e3
# bad: [7d843c494a9b69d07bc0588124599e3f665a1496] ALSA: firewire-motu: parse messages for input parameters in register DSP model
git bisect bad 7d843c494a9b69d07bc0588124599e3f665a1496
# bad: [90b28f3bb85c39b11daf29d473ef21a935c70ec5] ALSA: firewire-motu: add message parser for meter information in command DSP model
git bisect bad 90b28f3bb85c39b11daf29d473ef21a935c70ec5
# bad: [b96681bd58276e1c7ca4ca37bbaab9f8f1738d61] ALSA: usb-audio: Initialize every feature unit once at probe time
git bisect bad b96681bd58276e1c7ca4ca37bbaab9f8f1738d61
# good: [509975c7789f84b4d98e06fe2db51ee4ec02eef5] ALSA: usb-audio: Drop superfluous error message after disconnection
git bisect good 509975c7789f84b4d98e06fe2db51ee4ec02eef5
# first bad commit: [b96681bd58276e1c7ca4ca37bbaab9f8f1738d61] ALSA: usb-audio: Initialize every feature unit once at probe time
Thanks! That's an interesting result. This was thought to stabilize the behavior, but it doesn't seem to have some side-effect.
I guess the bug gets fixed if you revert the commit?
Also, with the broken kernel, did you get a warning message like below at the probe time:
X:Y: failed to get current value for ch X (X)?
Reverting b96681bd58276e1c7ca4ca37bbaab9f8f1738d61 on top of v5.16 fixes the issue.
I did not get any "failed to get current value for ch X" errors (I assume this would show up in the output of dmesg).
The "X" and "Y" are replaced with some numbers in the actual output. But the error messages might be already suppressed by the driver for some devices.
Basically this is an old problem that surfaced now due to the commit forcibly initializes each mixer element at probe time. The patch like below should "fix" the problem, just by ignoring the error. Could you check whether it works?
Created attachment 300451 [details]
Test fix patch
I know the X would be replaced, but there were no error messages of that form.
Your patch works for me.
@Takashi, I have been running the Arch LTS kernel (currently 5.15.22) which works. I just installed the regular kernel (currently 5.16.9) to confirm it still has this bug. Then I applied your patch to 5.16.9 sources to also confirm that the bug goes away. Thanks very much for your prompt work on this fix.
Good to hear.
The fix patch was submitted and merged to sound.git tree for the next PR:
It'll be backported to stable tree once after it gets merged to Linus tree.
*** Bug 215606 has been marked as a duplicate of this bug. ***