Bug 218816
Summary: | Deadlock between snd_ctl_elem_info and snd_pcm_dev_disconnect | ||
---|---|---|---|
Product: | Drivers | Reporter: | Richard van der Hoff (bugzilla) |
Component: | Sound(ALSA) | Assignee: | Jaroslav Kysela (perex) |
Status: | RESOLVED CODE_FIX | ||
Severity: | normal | CC: | tiwai |
Priority: | P3 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | Subsystem: | ||
Regression: | No | Bisected commit-id: | |
Attachments: |
dmesg
Test fix patch |
Could you try the patch below? Created attachment 306273 [details]
Test fix patch
And I think the second wake_up_all() call is superfluous and can be dropped. But let's check whether it really addresses the problem or not at first. OK, I could reproduce the problem by inserting an artificial delay at disconnect, and confirmed that the patch worked. The upstream submission: https://lore.kernel.org/all/20240510101424.6279-1-tiwai@suse.de/ It'll be included in 6.10-rc1, backported to stable tree eventually later. Feel free to reopen if the problem still persists with the patch above. Thanks. Thanks very much for investigating! It is my intention to try the patch; I've just not had time yet. It does indeed look like the patch posted to linux-sound fixes the problem. Thanks again! |
Created attachment 306269 [details] dmesg I regularly see a deadlock between `wireplumber` and a kernel thread handling a USB disconnect. I can reproduce this by disconnecting from my USB dock while the laptop is suspended, and then resuming. Attached is what I believe to be the relevant bits from dmesg, with `CONFIG_PROVE_LOCKING=y`. I've observed this on a range of kernels, including (Ubuntu's fork of) 6.5.13 and a vanilla 6.8.