From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09CD8C433DB for ; Fri, 22 Jan 2021 12:00:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C243722CA1 for ; Fri, 22 Jan 2021 12:00:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727610AbhAVMAV (ORCPT ); Fri, 22 Jan 2021 07:00:21 -0500 Received: from mx2.suse.de ([195.135.220.15]:47280 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727761AbhAVL7i (ORCPT ); Fri, 22 Jan 2021 06:59:38 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 443C9ABDA; Fri, 22 Jan 2021 11:58:57 +0000 (UTC) Date: Fri, 22 Jan 2021 12:58:57 +0100 Message-ID: From: Takashi Iwai To: Jamie Heilman Cc: linux-kernel@vger.kernel.org Subject: Re: bisected regression in v5.11-rc1 snd-usb-audio In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > 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 > > BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1178203 > > Signed-off-by: Takashi Iwai > > --- > > 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