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 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?
--Sean
