Skip to contentSkip to conversation

USB sound card freezes USB after resume from suspend

DISCUSSION Jakub Kicinski 4 participants 9 messages Apr 25, 2023 – Apr 26, 2023

Subsystems (3)
USB Sound Regressions
lore
Share & tools
lore

Jakub Kicinski

author
#0 lore raw

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.

#1 lore raw
Quoted 29 lines · Jakub Kicinski

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:

Quoted 7 lines

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)?

thanks,

Takashi

#2 lore raw

Hello Jakub and Takashi,

Quoted 7 lines · Takashi Iwai
Quoted 5 lines · Jakub Kicinski

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.

Takashi, did you pay attention to the workflow of triggering Jakub's bug? He suspends the computer with the sound card active, disconnects the sound card and expects to resume his computer back to an usable state.

IMHO this is a very believable report and I can see something going possibly wrong with this workflow. I understand you need the bisection from Jakub to get a clearer picture, I was just emphasizing the point that Jakub seems to be disconnecting the USB sound card during suspend and then resuming, at least that's what I was able to understand.

Thanks,
Geraldo Nascimento

Quoted 41 lines
Quoted 24 lines

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:

Quoted 7 lines

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)?

thanks,

Takashi

#3 lore raw
Quoted 9 lines · Geraldo Nascimento

Hello Jakub and Takashi,

Quoted 5 lines · Takashi Iwai
Quoted 3 lines · Jakub Kicinski

Hi!

Quoted 7 lines
Quoted 2 lines
Quoted 2 lines

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.

Takashi, did you pay attention to the workflow of triggering Jakub's bug? He suspends the computer with the sound card active, disconnects the sound card and expects to resume his computer back to an usable state.

It's a pretty normal procedure for many people; most of USB type-C docks have a USB audio built-in, and people remove the machine from the dock after suspend. So that's an operation that is seen everyday everywhere.

Still I haven't heard this issue, and it implies that it's either something new or specific to the machine or the environment. Or we've been just lucky...

Takashi

Quoted 51 lines

IMHO this is a very believable report and I can see something going possibly wrong with this workflow. I understand you need the bisection from Jakub to get a clearer picture, I was just emphasizing the point that Jakub seems to be disconnecting the USB sound card during suspend and then resuming, at least that's what I was able to understand.

Thanks,
Geraldo Nascimento

Quoted 41 lines
Quoted 24 lines

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:

Quoted 7 lines

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)?

thanks,

Takashi

#4 lore raw
Quoted 24 lines · Takashi Iwai
Quoted 9 lines · Geraldo Nascimento

Hello Jakub and Takashi,

Quoted 5 lines · Takashi Iwai
Quoted 3 lines · Jakub Kicinski

Hi!

Quoted 7 lines
Quoted 2 lines
Quoted 2 lines

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.

Takashi, did you pay attention to the workflow of triggering Jakub's bug? He suspends the computer with the sound card active, disconnects the sound card and expects to resume his computer back to an usable state.

It's a pretty normal procedure for many people; most of USB type-C docks have a USB audio built-in, and people remove the machine from the dock after suspend. So that's an operation that is seen everyday everywhere.

Quoted 6 lines

Still I haven't heard this issue, and it implies that it's either something new or specific to the machine or the environment. Or we've been just lucky...

Takashi

Understood, sorry for adding noise then.

Thanks,
Geraldo Nascimento

maintainer
#5 lore raw
In reply to Takashi Iwai
Quoted 36 lines · Takashi Iwai
Quoted 34 lines · Jakub Kicinski

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.

Quoted 7 lines
Quoted 2 lines

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.

But I cannot reproduce this lock here.

Jaroslav

Signature · 2 lines
Jaroslav Kysela <[email protected]>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
#6 lore raw
Quoted 61 lines · Jaroslav Kysela
Quoted 36 lines · Takashi Iwai
Quoted 34 lines · Jakub Kicinski

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.

Quoted 7 lines
Quoted 2 lines

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 }

Quoted 3 lines

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.

Quoted 1 line

But I cannot reproduce this lock here.

Here too. Could be tied with the config or the device?

thanks,

Takashi

-- 8< --

sound/core/pcm.c +0 -1
@@ -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(&register_mutex);
maintainer Reviewed-by
#7 lore raw
Quoted 63 lines · Takashi Iwai
Quoted 61 lines · Jaroslav Kysela
Quoted 36 lines · Takashi Iwai
Quoted 34 lines · Jakub Kicinski

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.

Quoted 7 lines
Quoted 2 lines

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 }

Quoted 5 lines
Quoted 3 lines

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.

It looks good.

Reviewed-by Jaroslav Kysela <[email protected]>
Quoted 5 lines

But we still need to figure out what's actually happening there.

Quoted 1 line

But I cannot reproduce this lock here.

Here too. Could be tied with the config or the device?

Perhaps. Jakub, could you do more debugging (printk, traces)?

Jaroslav

Signature · 2 lines
Jaroslav Kysela <[email protected]>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
author
#8 lore raw
Quoted 6 lines · On Wed, 26 Apr 2023 13:04:15 +0200 Jaroslav Kysela wrote:
Quoted 1 line

A good point, it'll be a patch like below.

It looks good.

Reviewed-by Jaroslav Kysela <[email protected]>
Quoted 7 lines
Quoted 5 lines

But we still need to figure out what's actually happening there.

Quoted 1 line

But I cannot reproduce this lock here.

Here too. Could be tied with the config or the device?

Perhaps. Jakub, could you do more debugging (printk, traces)?

Let me get back to you on Saturday - I'll test the patch and try a bit of bisecting. Can't promise much in terms of printing, because IDK what to print :(