USB sound card freezes USB after resume from suspend
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.
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)?
thanks,
Takashi
Hello Jakub and Takashi,
On Wed, Apr 26, 2023 at 07:24:50AM +0200, 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.
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
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)?
thanks,
Takashi
On Wed, 26 Apr 2023 07:46:47 +0200, Geraldo Nascimento wrote:
Hello Jakub and Takashi,
On Wed, Apr 26, 2023 at 07:24:50AM +0200, 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.
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
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
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)?
thanks,
Takashi
On Wed, Apr 26, 2023 at 08:02:58AM +0200, Takashi Iwai wrote:
On Wed, 26 Apr 2023 07:46:47 +0200, Geraldo Nascimento wrote:
Hello Jakub and Takashi,
On Wed, Apr 26, 2023 at 07:24:50AM +0200, 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.
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
Understood, sorry for adding noise then.
Thanks, Geraldo Nascimento
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.
But I cannot reproduce this lock here.
Jaroslav
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);
On 26. 04. 23 10:14, Takashi Iwai wrote:
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.
It looks good.
Reviewed-by: Jaroslav Kysela perex@perex.cz
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?
Perhaps. Jakub, could you do more debugging (printk, traces)?
Jaroslav
On Wed, 26 Apr 2023 13:04:15 +0200 Jaroslav Kysela wrote:
A good point, it'll be a patch like below.
It looks good.
Reviewed-by: Jaroslav Kysela perex@perex.cz
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?
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 :(
participants (4)
-
Geraldo Nascimento -
Jakub Kicinski -
Jaroslav Kysela -
Takashi Iwai