Bug 206147

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