Created attachment 286719 [details] relevant lsusb -vvv snippet Device: M-Audio Fast Track C400 (0763:2030) After Fedora upgraded to 5.3, ALSA can't play or control the device. It is still listed in /proc/asound/cards: 2 [C400 ]: USB-Audio - Fast Track C400 M-Audio Fast Track C400 at usb-0000:00:14.0-2, high speed ...but aplay -l doesn't list it; playing with `aplay -D hw:2 somefile.wav` results in: aplay: main:828: audio open error: No such file or directory alsamixer lists the device but doesn't show any controls: "This sound device does not have any controls." The relevant dmesg lines: [ 187.105348] usb 2-2: new high-speed USB device number 6 using xhci_hcd [ 187.233711] usb 2-2: New USB device found, idVendor=0763, idProduct=2030, bcdDevice= 1.01 [ 187.233715] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 187.233718] usb 2-2: Product: Fast Track C400 [ 187.233720] usb 2-2: Manufacturer: M-Audio [ 187.237756] input: M-Audio Fast Track C400 as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.5/0003:0763:2030.0002/input/input18 [ 187.290136] hid-generic 0003:0763:2030.0002: input,hidraw1: USB HID v1.10 Keyboard [M-Audio Fast Track C400] on usb-0000:00:14.0-2/input5 [ 187.552672] usbcore: registered new interface driver snd-usb-audio With kernel 5.2.18 the device works correctly.
Created attachment 286721 [details] dmesg on 5.2
Created attachment 286723 [details] dmesg on 5.3
Rather check lsusb -v output on both 5.2 and 5.3 kernels. But, other than that, I have no clue; the best would be to go for bisection...
Tested kernel versions: 5.2.18-200.fc30.x86_64 - OK 5.3.16-200.fc30.x86_64 - fails 5.4.7-100.fc30.x86_64 - fails
(In reply to Takashi Iwai from comment #3) > Rather check lsusb -v output on both 5.2 and 5.3 kernels. > > But, other than that, I have no clue; the best would be to go for > bisection... I have attached 5.3 lsusb above, going for reboot for the 5.2 one.
Created attachment 286725 [details] lsusb -vvv on 5.2.18 Attaching lsusb on 5.2.18; there is no difference except the bus device id.
Starting a bisect.
My bisect landed me at something very strange. Maybe I mis-performed the bisect somehow, but I have no idea what can be wrong... # git bisect log # bad: [128f430ae9acb403059d02d9bbcbd9dcf52968a0] Linux 5.3.16 # good: [0a9d6a58b4acfa52384b3175bd3d0742467bcf65] Linux 5.2.18 git bisect start 'v5.3.16' 'v5.2.18' # good: [0ecfebd2b52404ae0c54a878c872bb93363ada36] Linux 5.2 git bisect good 0ecfebd2b52404ae0c54a878c872bb93363ada36 # skip: [168869492e7009b6861b615f1d030c99bc805e83] docs: kbuild: fix build with pdf and fix some minor issues git bisect skip 168869492e7009b6861b615f1d030c99bc805e83 # skip: [55167453111d3a1e600e29ba6c8e63906bb4821b] Merge tag 'platform-drivers-x86-v5.3-1' of git://git.infradead.org/linux-platform-drivers-x86 git bisect skip 55167453111d3a1e600e29ba6c8e63906bb4821b # good: [f3386e45be13564d87bf8907361df096e581d676] blkcg: make blkcg_print_stat() print stats only for online blkgs git bisect good f3386e45be13564d87bf8907361df096e581d676 # bad: [238e5e0984c53e759d1cd908f94113e175db0aca] x86/xen/32: Simplify ring check in xen_iret_crit_fixup() git bisect bad 238e5e0984c53e759d1cd908f94113e175db0aca # bad: [f5c0fa62ddab7696cd3f42b637e450f4b8caf4e8] ASoC: SOF: Intel: hda-stream: fix the CONFIG_ prefix missing git bisect bad f5c0fa62ddab7696cd3f42b637e450f4b8caf4e8 # bad: [19be57ee528ed93d8fc25779332e2c196f0d10bd] iwlwifi: pcie: fix PCI ID 0x2720 configs that should be soc git bisect bad 19be57ee528ed93d8fc25779332e2c196f0d10bd # good: [3b17a13b687ae99939dc94a4ae01fbc34f68decc] ALSA: usb-audio: Remove superfluous bLength checks git bisect good 3b17a13b687ae99939dc94a4ae01fbc34f68decc # good: [40599d1a46afc43a340b8f5aa1659dafedc47fd1] IB/core: Use rdma_read_gid_l2_fields to compare GID L2 fields git bisect good 40599d1a46afc43a340b8f5aa1659dafedc47fd1 # bad: [24665ff0d06a6bdf3e9abe1b558d1efb38c38c33] scsi: ufs-bsg: Wake the device before sending raw upiu commands git bisect bad 24665ff0d06a6bdf3e9abe1b558d1efb38c38c33 # bad: [38dc6b5959af978740b50a50ca229f73f701b578] net/mlx5: fix memory leak in mlx5_fw_fatal_reporter_dump git bisect bad 38dc6b5959af978740b50a50ca229f73f701b578 # bad: [7bf82947c2a79aef7e561ce654b276d753a05483] net/mlx5e: kTLS, Release reference on DUMPed fragments in shutdown flow git bisect bad 7bf82947c2a79aef7e561ce654b276d753a05483 # bad: [0dc9c29cfad04129fcc33af89fa274941d8c61d8] net/mlx5e: Tx, Fix assumption of single WQEBB of NOP in cleanup flow git bisect bad 0dc9c29cfad04129fcc33af89fa274941d8c61d8 # first bad commit: [0dc9c29cfad04129fcc33af89fa274941d8c61d8] net/mlx5e: Tx, Fix assumption of single WQEBB of NOP in cleanup flow
Okay, ignore the previous bisect. I did another one, first by manually narrowing down the search to two consecutive kernel versions - 5.3.10 (good) and 5.3.11 (bad), and doing a bisect from there. Git bisect then pointed me to the following commit: c07240f4150bb16193d1fd977f702671cf3d1ff3 is the first bad commit commit c07240f4150bb16193d1fd977f702671cf3d1ff3 Author: Takashi Iwai <tiwai@suse.de> Date: Fri Aug 23 12:38:07 2019 +0200 ALSA: usb-audio: Clean up check_input_term() commit e0ccdef92653f8867e2d1667facfd3c23699f540 upstream. The primary changes in this patch are cleanups of __check_input_term() and move to a non-nested switch-case block by evaluating the pair of UAC version and the unit type, as we've done for parse_audio_unit(). Also each parser is split into the function for readability. Now, a slight behavior change by this cleanup is the handling of processing and extension units. Formerly we've dealt with them differently between UAC1/2 and UAC3; the latter returns an error if no input sources are available, while the former continues to parse. In this patch, unify the behavior in all cases: when input sources are available, it parses recursively, then override the type and the id, as well as channel information if not provided yet. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> :040000 040000 1b268118f1c7e6c5a0ab752e1661caeef46a34ce c61db07ef73894558e2c43259d75286622025016 M sound
Created attachment 287163 [details] successful bisect log between 5.3.10 and 5.3.11
Thanks, this looks more reasonable. Now could you give alsa-info.sh output from the working kernel? Run the script with --no-upload option and attach to Bugzilla. Also, give the contents of /proc/asound/card*/usbmixer, too.
Created attachment 287173 [details] result of alsa-info.sh
Created attachment 287175 [details] content of /proc/asound/card2/usbmixer
I`m getting the same behaviour with kernel 5.5.2
Could you try the patch below? There seems the inconsistency about handling of UAC2 effect unit descriptor.
Created attachment 287307 [details] Test fix patch
(In reply to Takashi Iwai from comment #15) > Could you try the patch below? There seems the inconsistency about handling > of UAC2 effect unit descriptor. I rebuilded snd-usb-audio module with your patch, aparently it's works, nothing to complain. Thank you so much! Will you integrate this patch to your GitHub repository?
Good to hear. Now the patch was submitted and merged to sound git tree. It'll be included in 5.6-rc2, and will be backported to stable kernels later.
Created attachment 287309 [details] Revised fix patch
One more favor: could you check whether applying the patch below in addition to the previous one causes any problem? In the previous patch, we haven't parsed the source of the effect unit, but we should do it basically. The additional patch does it (only partially -- the actual parse of effect unit isn't done but implemented by device-specific quirks, so far).
Created attachment 287323 [details] Additional patch for UAC2 effect unit descriptor
Created attachment 287325 [details] Additional patch for UAC2 effect unit descriptor (fixed) Now attached the correct version.
I confirm that this patch fixes the issue (applied against 5.4.17 ,Fedora's current kernel). Thank you!
(In reply to Takashi Iwai from comment #22) > Created attachment 287325 [details] > Additional patch for UAC2 effect unit descriptor (fixed) > > Now attached the correct version. This last version of patch, doesn't work for me. This section don't match... 903 { 904 struct uac_clock_source_descriptor *d = p1; 905 906 term->type = UAC3_CLOCK_SOURCE << 16; /* virtual type */ 907 term->id = id; 908 term->name = d->iClockSource; 909 return 0; 910 }
You meant the patch in comment 22 as the last version? It must be applied on top of the patch in comment 19.
(In reply to Takashi Iwai from comment #25) > You meant the patch in comment 22 as the last version? It must be applied > on top of the patch in comment 19. Sorry, my mistake... It's working as well.
The second patch works on my side as well. I might have a chance to test a FastTrack C600 too (a very similar device to C400) soon, if I discover any problems, I can follow up.
Thanks for the feedback!
(In reply to Takashi Iwai from comment #28) > Thanks for the feedback! Can You help-me with this? https://bugzilla.kernel.org/show_bug.cgi?id=214817