Re: bisected regression in v5.11-rc1 snd-usb-audio

[Takashi Iwai]

On Fri, 22 Jan 2021 11:03:48 +0100,
Jamie Heilman wrote:
> 
> Takashi Iwai wrote:
> > You seem hitting a firmware bug, and it doesn't look like the only
> > case.  Interestingly, the backport of 5.11 USB-audio stuff on 5.3
> > kernel on openSUSE Leap 15.2 caused a similar bug on Steinberg device,
> > while it worked with 5.11-rc.  So I thought this specific with the
> > older kernel (in USB core changes or such), but my guess seems wrong,
> > and the bug looks remaining in 5.11 for some cases.
> > 
> > Below is the fix patch.  Please give it a try.
> > 
> > 
> > thanks,
> > 
> > Takashi
> > 
> > -- 8< --
> > From: Takashi Iwai <tiwai@xxxxxxx>
> > Subject: [PATCH] ALSA: usb-audio: workaround for iface reset issue
> > 
> > The recently introduced sample rate validation code seems causing a
> > problem on some devices; namely, after performing this, the bus gets
> > screwed and it influences even on other USB devices.
> > As a quick workaround, perform it only for the necessary devices;
> > currently MOTU devices are known to need the valid altset checks, so
> > filter out other devices.
> > 
> > Fixes: 93db51d06b32 ("ALSA: usb-audio: Check valid altsetting at parsing rates for UAC2/3")
> > Reported-by: Jamie Heilman <jamie@xxxxxxxxxxxxxxxxxxxxx>
> > BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1178203
> > Signed-off-by: Takashi Iwai <tiwai@xxxxxxx>
> > ---
> >  sound/usb/format.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/sound/usb/format.c b/sound/usb/format.c
> > index 9ebc5d202c87..e6ff317a6785 100644
> > --- a/sound/usb/format.c
> > +++ b/sound/usb/format.c
> > @@ -466,6 +466,17 @@ static int validate_sample_rate_table_v2v3(struct snd_usb_audio *chip,
> >  	unsigned int nr_rates;
> >  	int i, err;
> >  
> > +	/* performing the rate verification may lead to unexpected USB bus
> > +	 * behavior afterwards by some unknown reason.  Do this only for the
> > +	 * known devices.
> > +	 */
> > +	switch (USB_ID_VENDOR(chip->usb_id)) {
> > +	case 0x07fd: /* MOTU */
> > +		break;
> > +	default:
> > +		return 0; /* don't perform the validation as default */
> > +	}
> > +
> >  	table = kcalloc(fp->nr_rates, sizeof(*table), GFP_KERNEL);
> >  	if (!table)
> >  		return -ENOMEM;
> 
> Well, with this patch, while I can get it to seemingly initialize
> without errors by replugging, I can't actually get it to work.  Jack
> says:
> 
> Starting jack server...
> JACK server starting in realtime mode with priority 10
> self-connect-mode is "Don't restrict self connect requests"
> Acquired audio card Audio1
> creating alsa driver ... hw:CARD=hiFace2,DEV=0|-|1024|3|96000|0|0|nomon|swmeter|-|32bit
> ERROR: ALSA: Cannot open PCM device alsa_pcm for playback. Falling back to capture-only mode
> Released audio card Audio1
> ERROR: Cannot initialize driver
> ERROR: JackServer::Open failed with -1
> ERROR: Failed to open server

Which kernel did you test?  There have been a few more USB-audio fixes
that landed to Linus tree yesterday, so you'd need to test with it (in
addition to the previous patch).

> here's what aplay does when it tries:
> 
> aplay: main:830: audio open error: Invalid argument
> 
> strace of that says:
> openat(AT_FDCWD, "/dev/snd/pcmC1D0p", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EINVAL (Invalid argument)

Hm, it's weird that open returns -EINVAL, not the later ioctl...

> I dug up a different USB sound device (bithead) and plugged it in, it
> still works just fine with the same commands.
> 
> The only difference I see in the alsa-info output is that
> 
>         control.7 {
>                 iface CARD
>                 name 'Keep Interface'
>                 value false
>                 comment {
>                         access 'read write'
>                         type BOOLEAN
>                         count 1
>                 }
>         }
> 
> has gone missing.

This is an intended change and should be irrelevant.

If the problem is still seen with the very latest Linus tree and the
previous patch, please enable the dyndbg, e.g. pass dydbg=+p option to
snd-usb-audio module, i.e. reload like
   modprobe snd-usb-audio dydbg=+p
or boot with
   snd_usb_audio.dyndbg=+p
boot option, retest, and give the kernel messages.


thanks,

Takashi