Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 02 Sep 2022 07:52:29 +0200
Message-ID: <87v8q6wcf6.wl-tiwai@suse.de>
From:   Takashi Iwai <tiwai@suse.de>
To:     Sean Anderson <sean.anderson@seco.com>
Cc:     Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
        alsa-devel@alsa-project.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: retire_capture_urb: Corrected urb data len
In-Reply-To: <53306c0f-e5ef-44ee-b90c-a3ea61ca454c@seco.com>
References: <68a97d61-21bf-b45e-f6ed-c0906dd4b197@seco.com>
        <87ilmfj72j.wl-tiwai@suse.de>
        <9d41eda1-1172-ea60-dd87-b3e38a529170@seco.com>
        <87r110iz8w.wl-tiwai@suse.de>
        <53306c0f-e5ef-44ee-b90c-a3ea61ca454c@seco.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Thu, 01 Sep 2022 17:25:41 +0200,
Sean Anderson wrote:
> 
> 
> 
> On 8/28/22 3:49 AM, Takashi Iwai wrote:
> > On Fri, 26 Aug 2022 20:57:53 +0200,
> > Sean Anderson wrote:
> >> 
> >> On 8/26/22 12:36 PM, Takashi Iwai wrote:
> >> > On Fri, 26 Aug 2022 18:22:24 +0200,
> >> > Sean Anderson wrote:
> >> >> 
> >> >> Hi all,
> >> >> 
> >> >> I have a "FiiO DigiHug USB Audio" sound card (1852:7022) [3]. I have had
> >> >> no problems with the audio, but I did notice a large number of message
> >> >> like 
> >> >> 
> >> >> retire_capture_urb: 4992 callbacks suppressed
> >> >> 
> >> >> in my dmesg [1]. This is caused by the "Corrected urb data len."
> >> >> warning.
> >> > 
> >> > What exact values are shown there?
> >> 
> >> Unfortunately, as detailed below, I was unable to turn off ratelimiting.
> >> 
> >> > The problem is that your hardware
> >> > (likely a buggy firmware) returns the unaligned size of bytes as the
> >> > data.  Maybe it's worth to replace dev_warn_ratelimited() there with
> >> > dev_warn() and take all warnings once.  Then we can see what kind of
> >> > values are delivered from the hardware.
> >> 
> >> I'll have an attempt at that next week
> >> 
> >> >> The patch adding this warning [2] makes it seem like
> >> >> this warning should be an uncommon occurance. However, based on the
> >> >> number of suppressed callbacks, this seems to be happening at a rate of
> >> >> around 500 Hz.
> >> >> 
> >> >> Is this buggy hardware? Or is this a bug in the driver? Does there need
> >> >> to be a quirk? Or perhaps the warning above should be a debug instead?
> >> > 
> >> > There is no quirk for that.  As long as the device works with that
> >> > workaround (except for messages), we can simply add a quirk to not
> >> > warn but always apply the workaround silently for such devices.
> >> 
> >> OK. I wasn't sure what the correct resolution would be.
> > 
> > Actually I was wrong: the existing quirk QUIRK_FLAG_ALIGN_TRANSFER
> > should cover that.
> > 
> > Could you try to pass quirk_flags=0x04 for the corresponding card slot
> > (the option takes an array) to snd-usb-audio module?  Alternatively,
> > try to pass quirk_alias=18557022:0e510408 to snd-usb-audio?
> 
> I tried both options, but neither worked.

I have no further idea.  You should try the latest kernel without
modification before checking further.

And, looking at the code again, it's really strange that you get those
messages.  Actually the transfer size *is* aligned to the audio frames
as default *unless* QUIRK_FLAG_ALIGN_TRANSFER is passed.  And the
check is done rather the audio sample size alignment -- which must fit
within the audio frame alignment.

So, QUIRK_FLAG_ALIGN_TRANSFER is already set for your device by some
reason incorrectly, or the code is doing wrong on your kernel.
We need to check what values are shown there actually, then check
whether the problem happens with the latest vanilla kernel.


Takashi