On Wed, 26 Apr 2023 10:01:11 +0200,
Jaroslav Kysela wrote:
>
> On 26. 04. 23 7:24, Takashi Iwai wrote:
> > On Tue, 25 Apr 2023 20:19:24 +0200,
> > Jakub Kicinski wrote:
> >>
> >> Hi!
> >>
> >> For a few weeks now I can't use any USB devices if I suspend my laptop
> >> with my USB sound card active and resuming it without it connected.
> >>
> >> USB worker threads seems to be sitting in:
> >>
> >> [<0>] snd_pcm_dev_disconnect+0x1e8/0x280 [snd_pcm]
> >> [<0>] snd_device_disconnect_all+0x42/0x80 [snd]
> >> [<0>] snd_card_disconnect+0x128/0x290 [snd]
> >> [<0>] usb_audio_disconnect+0x11a/0x2c0 [snd_usb_audio]
> >> [<0>] usb_unbind_interface+0x8c/0x270
> >> [<0>] device_release_driver_internal+0x1b2/0x230
> >> [<0>] bus_remove_device+0xd8/0x150
> >> [<0>] device_del+0x18b/0x410
> >> [<0>] usb_disable_device+0xc6/0x1e0
> >> [<0>] usb_disconnect+0xda/0x2c0
> >> [<0>] usb_disconnect+0xbf/0x2c0
> >> [<0>] usb_disconnect+0xbf/0x2c0
> >> [<0>] usb_disconnect+0xbf/0x2c0
> >> [<0>] hub_event+0xf01/0x1cd0
> >> [<0>] process_one_work+0x1c4/0x3d0
> >> [<0>] worker_thread+0x4d/0x380
> >> [<0>] kthread+0xe6/0x110
> >> [<0>] ret_from_fork+0x29/0x50
> >>
> >> Which is:
> >>
> >> snd_pcm_dev_disconnect (/usr/src/debug/kernel-6.2.12/linux-6.2.12-300.fc38.x86_64/sound/core/pcm.c:818 /usr/src/debug/kernel-6.2.12/linux-6.2.12-300.fc38.x86_64/sound/core/pcm.c:812 /usr/src/debug/kernel-6.2.12/linux-6.2.12-300.fc38.x86_64/sound/core/pcm.c:1129) snd_pcm
> >>
> >> It happens on Fedora 37 and Fedora 38, it seems to have coincided with
> >> the 6.2 kernel but I'm not 100% sure.
> >>
> >> The USB devices come back after half an hour or so, silently.
> >> There's nothing of note in dmesg.
> >
> > AFAIK, there has been no similar report, so far.
> >
> > Is it a regression? If yes, could you figure out which kernel version
> > starts showing the problem (or at best bisection)?
>
> It seems that it may be related to free_chmap():
>
> (gdb) l *(snd_pcm_dev_disconnect+0x1e8)
> 0xef0 is in snd_pcm_dev_disconnect (sound/core/pcm.c:817).
> 812 static void free_chmap(struct snd_pcm_str *pstr)
> 813 {
> 814 if (pstr->chmap_kctl) {
> 815 struct snd_card *card = pstr->pcm->card;
> 816
> 817 down_write(&card->controls_rwsem);
> 818 snd_ctl_remove(card, pstr->chmap_kctl);
> 819 up_write(&card->controls_rwsem);
> 820 pstr->chmap_kctl = NULL;
> 821 }
>
> I think that the chmap should be freed only in snd_pcm_free_stream()
> to avoid possible nested mutex locks. This operation does not belong
> to disconnect.
A good point, it'll be a patch like below.
But we still need to figure out what's actually happening there.
> But I cannot reproduce this lock here.
Here too. Could be tied with the config or the device?
thanks,
Takashi
-- 8< --
--- a/sound/core/pcm.c
+++ b/sound/core/pcm.c
@@ -1126,7 +1126,6 @@ static int snd_pcm_dev_disconnect(struct snd_device *device)
pcm_call_notify(pcm, n_disconnect);
for (cidx = 0; cidx < 2; cidx++) {
snd_unregister_device(&pcm->streams[cidx].dev);
- free_chmap(&pcm->streams[cidx]);
}
mutex_unlock(&pcm->open_mutex);
mutex_unlock(®ister_mutex);
