Reproduceable hung-task in snd_usb_pcm or usb-core in VM with Behringer device. Hello maintainers of usb, I found a reproduceable hung-task problem when trying to use Behringer "Uphoria" audio devices inside VMware workstation, on Debian-SID with kernel 5.7 or with 5.8-rc5 . Kernel-trace and USB IDs are included. Am I right to post here? The problem occurs every time when accessing the devices. The problem does NOT occur with: - another sound device (griffin) - on native Linux on another machine I cannot tell if it is a bug with VMware, the Behringer audio devices, or if this might point to a bug in snd_usb_pcm. If you have an idea what to try I can apply patches, rebuild kernel and try if an improvement works. The system is a Debian-10 'unstable', running inside VMware 15.5.5 . I tried first the kernel 5.7.0 which comes with Debian-sid, and then a self-built 5.8-rc5, in which I activated the hung-task detection to get the traces. The two Behringer devices tried are these: USB ID 1397:0509, "BEHRINGER Internaltional GmbH UMC404HD 192k" USB ID 1397:0507, "BEHRINGER International GmbH UMC202HD 192k" lsusb -vv information attached as tar.gz The first is a 4-channel device, the second a 2-channel. Both support 192kHz, 24bit. In the native Linux and on Windows-10 both devices work fine. When connecting the device, the kernel log already points out some problems? [ 62.084753] usb 2-1: new high-speed USB device number 2 using ehci-pci [ 62.494602] usb 2-1: New USB device found, idVendor=1397, idProduct=0509, bcdDevice= 1.12 [ 62.497558] usb 2-1: New USB device strings: Mfr=1, Product=3, SerialNumber=0 [ 62.500158] usb 2-1: Product: UMC404HD 192k [ 62.501660] usb 2-1: Manufacturer: BEHRINGER [ 62.539826] mc: Linux media interface: v0.10 [ 64.121247] usbcore: registered new interface driver snd-usb-audio [ 65.718107] usb 2-1: timeout: still 3 active urbs on EP #81 [ 66.717880] usb 2-1: timeout: still 12 active urbs on EP #1 [ 67.722105] usb 2-1: timeout: still 3 active urbs on EP #81 [ 68.722097] usb 2-1: timeout: still 12 active urbs on EP #1 LAter, when trying to access the device by calling for 'pavucontrol', I can wait 2 mins then get the hung-task: [ 243.337022] INFO: task pulseaudio:762 blocked for more than 120 seconds. [ 243.339607] Tainted: G W E 5.8.0-rc5+ #1 [ 243.341652] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 243.344445] pulseaudio D 0 762 743 0x00000120 [ 243.346478] Call Trace: [ 243.347401] __schedule+0x361/0x950 [ 243.348665] schedule+0x4a/0xb0 [ 243.349922] usb_kill_urb+0x7d/0xb0 [usbcore] [ 243.351373] ? finish_wait+0x80/0x80 [ 243.352282] usb_hcd_flush_endpoint+0xb4/0x170 [usbcore] [ 243.353514] usb_disable_endpoint+0xa6/0xb0 [usbcore] [ 243.354647] usb_disable_interface+0x3c/0x50 [usbcore] [ 243.355796] usb_set_interface+0x69/0x2f0 [usbcore] [ 243.356931] snd_usb_pcm_close+0x92/0xc0 [snd_usb_audio] [ 243.358131] snd_pcm_release_substream.part.0+0x40/0xa0 [snd_pcm] [ 243.359484] snd_pcm_release+0x54/0xb0 [snd_pcm] [ 243.360520] __fput+0xe3/0x250 [ 243.361260] task_work_run+0x5f/0x90 [ 243.362082] __prepare_exit_to_usermode+0x1b5/0x1c0 [ 243.363173] do_syscall_64+0x62/0xe0 [ 243.363983] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 243.365173] RIP: 0033:0x7fcfb3f6ebd7 [ 243.365970] Code: Bad RIP value. [ 243.366626] RSP: 002b:00007ffedc79baa8 EFLAGS: 00000202 ORIG_RAX: 000000000000000b [ 243.368140] RAX: 0000000000000000 RBX: 000055d40175cdb8 RCX: 00007fcfb3f6ebd7 [ 243.369595] RDX: 0000000000000010 RSI: 0000000000001000 RDI: 00007fcfb4459000 [ 243.371087] RBP: 000055d40175c710 R08: 0000000000000000 R09: 00007ffedc79ba40 [ 243.372599] R10: 000055d4015a0250 R11: 0000000000000202 R12: 0000000000000000 [ 243.374123] R13: 00007ffedc79baf4 R14: 000055d4016747e0 R15: 000055d4015e63c0 [ 243.375639] INFO: lockdep is turned off. The output of lsusb -vv is taken from the native linux machine, as this call also locks up in the VM. Attached is the kernel-log of the whole run, just in case it might contain some intesting information. The host of the VMware VM is a Win10 system with an AMD Rhyzen7. Sincerly Achim Dahlhoff.
Attachment:
kernel_full_log.txt.gz
Description: Binary data
Attachment:
lsusb_data.tar.gz
Description: Binary data
