Re: retire_capture_urb: Corrected urb data len

[Takashi Iwai <tiwai@suse.de>]

On Thu, 31 Jul 2025 23:49:11 +0200,
Sean Anderson wrote:
> 
> Hi,
> 
> On 9/2/22 01:52, Takashi Iwai wrote:
> > 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.
> 
> Sorry for the very long hiatus. I have reproduced this issue on kernel
> 6.15.8.
> 
> From closer inspection this message seems to be from the first print and
> not the second one:
> 
> if (urb->iso_frame_desc[i].status && printk_ratelimit()) {
> 	dev_dbg(&subs->dev->dev, "frame %d active: %d\n",
> 		i, urb->iso_frame_desc[i].status);
> 	// continue;
> }
> 
> This probably be a dev_dbg_ratelimited. Indeed, that suppresses these
> messages.

The use or printk_ratelimit() like the above is already discouraged,
so it makes more sense to switch to dev_dbg_ratelimited() if it
works.

> The actual message that's being ratelimited is
> 
> usb 3-11.2: frame 0 active: -71
> 
> which is EPROTO. Looks like that comes from xhci_hcd. With debug enabled
> I get a lot of
> 
> xhci_hcd 0000:80:14.0: Transfer error for slot 36 ep 4 on endpoint
> 
> The spec says this is 
> 
> | Asserted in the case where the host did not receive a valid response
> | from the device (Timeout, CRC, Bad PID, unexpected NYET, etc.).
> 
> and I don't really know what to make of that. Should I send a patch to
> convert that dev_dbg to dev_dbg_ratelimited? Or do you want to debug
> this further?

Usually EPROTO means something the USB controller doesn't like :)
It's often a device firmware problem, but can be other means, too.
You can try to connect to a different port or a machine, and see
whether the problem is seen consistently.


thanks,

Takashi