public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: "Robert Ham" <rah@settrans.net>, "Michał Pecio" <michal.pecio@gmail.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: Audio interface causing "xhci_hcd ... WARN: buffer overrun event" messages
Date: Thu, 31 Jul 2025 17:26:07 +0300	[thread overview]
Message-ID: <f277779a-34af-4db0-bef0-fa41aa538f97@linux.intel.com> (raw)
In-Reply-To: <3bbb710c-351d-46ec-a2e4-9ee4d766a750@settrans.net>

On 31.7.2025 13.11, Robert Ham wrote:
> I managed to sort out the tracing and debug output. Updated kernel log
> and trace:
> 
> https://settrans.net/~rah/misc/xhci-kernel-log-2.txt
> 
> https://settrans.net/~rah/misc/xhci-kernel-trace-2.txt
> 
> 
> On 31/07/2025 09:27, Michał Pecio wrote:
> 
>> Can you post "lsusb -v" for this device?
> 

Looks like The lengths and offsets in the URB, passed by audio driver does
not match the transfer sizes the device reports it will send.

The audio device reports its isoc endpoint will send 1000 bytes
every 125 microseconds:
(from your lsusb)

>        Endpoint Descriptor:
>          bLength                 7
>          bDescriptorType         5
>          bEndpointAddress     0x81  EP 1 IN
>          bmAttributes           37
>            Transfer Type            Isochronous
>            Synch Type               Asynchronous
>            Usage Type               Implicit feedback Data
>          wMaxPacketSize     0x03e8  1x 1000 bytes
>          bInterval               1

Trace shows xhci sets up the endpoint correctly,
expecting 1000 bytes every 125 mictoseconds:

pulseaudio-1435    [000] .....    55.126749: xhci_ring_alloc: ISOC 00000000c42321b6: enq 0x00000002483a2000(0x00000002483a2000) deq 0x00000002483a2000(0x00000002483a2000) segs 2 stream 0 bounce 1000 cycle 1
pulseaudio-1435    [000] .....    55.126750: xhci_add_endpoint: State disabled mult 1 max P. Streams 0 interval 125 us max ESIT payload 1000 CErr 0 Type Isoc IN burst 0 maxp 1000 deq 00000002483a2001 avg trb len 1000

but the URB queued from class driver to xhci doesn't match this.
Looks like one URB contains 8 isoc transfers, (one filled every 125us) but URB expects
only 2880 bytes in total, leading to only 360 bytes per isoc transfer.

I'd take a closer look at the values filled by the audio driver to the
struct usb_iso_packet_descriptor iso_frame_desc[] array, and number_of_packets
in the URB

usbmon might show these, don't remember if it shows all isoc related fields

Trace shoes the URB turned into Isoc TRBs of 360 bytes by xhci driver.
Notice that the Buffer address also increases only by 360 bytes (0x168)
  
55.198885: xhci_urb_enqueue: 3-5.1 ep1in-isoc: urb 0000000052d17659 pipe 33920 slot 3 length 0/2880 sgs 0/0 stream 0 flags 00000204
55.198892: xhci_queue_trb: ISOC: Buffer 0000000104735000 length 360 TD size 0 intr 0 type 'Isoch' flags B:i:I:c:s:I:e:c
55.198892: xhci_inc_enq: ISOC 00000000c42321b6: enq 0x00000002483a2010(0x00000002483a2000) deq 0x00000002483a2000(0x00000002483a2000) segs 2 stream 0 bounce 1000 cycle 1
55.198894: xhci_queue_trb: ISOC: Buffer 0000000104735168 length 360 TD size 0 intr 0 type 'Isoch' flags B:i:I:c:s:I:e:C
55.198894: xhci_inc_enq: ISOC 00000000c42321b6: enq 0x00000002483a2020(0x00000002483a2000) deq 0x00000002483a2000(0x00000002483a2000) segs 2 stream 0 bounce 1000 cycle 1
55.198895: xhci_queue_trb: ISOC: Buffer 00000001047352d0 length 360 TD size 0 intr 0 type 'Isoch' flags B:i:I:c:s:I:e:C
55.198896: xhci_inc_enq: ISOC 00000000c42321b6: enq 0x00000002483a2030(0x00000002483a2000) deq 0x00000002483a2000(0x00000002483a2000) segs 2 stream 0 bounce 1000 cycle 1
55.198897: xhci_queue_trb: ISOC: Buffer 0000000104735438 length 360 TD size 0 intr 0 type 'Isoch' flags B:i:I:c:s:I:e:C
55.198897: xhci_inc_enq: ISOC 00000000c42321b6: enq 0x00000002483a2040(0x00000002483a2000) deq 0x00000002483a2000(0x00000002483a2000) segs 2 stream 0 bounce 1000 cycle 1
55.198899: xhci_queue_trb: ISOC: Buffer 00000001047355a0 length 360 TD size 0 intr 0 type 'Isoch' flags B:i:I:c:s:I:e:C
55.198899: xhci_inc_enq: ISOC 00000000c42321b6: enq 0x00000002483a2050(0x00000002483a2000) deq 0x00000002483a2000(0x00000002483a2000) segs 2 stream 0 bounce 1000 cycle 1
55.198900: xhci_queue_trb: ISOC: Buffer 0000000104735708 length 360 TD size 0 intr 0 type 'Isoch' flags B:i:I:c:s:I:e:C
55.198900: xhci_inc_enq: ISOC 00000000c42321b6: enq 0x00000002483a2060(0x00000002483a2000) deq 0x00000002483a2000(0x00000002483a2000) segs 2 stream 0 bounce 1000 cycle 1
55.198901: xhci_queue_trb: ISOC: Buffer 0000000104735870 length 360 TD size 0 intr 0 type 'Isoch' flags B:i:I:c:s:I:e:C
55.198902: xhci_inc_enq: ISOC 00000000c42321b6: enq 0x00000002483a2070(0x00000002483a2000) deq 0x00000002483a2000(0x00000002483a2000) segs 2 stream 0 bounce 1000 cycle 1
55.198903: xhci_queue_trb: ISOC: Buffer 00000001047359d8 length 360 TD size 0 intr 0 type 'Isoch' flags b:i:I:c:s:I:e:C
55.198903: xhci_inc_enq: ISOC 00000000c42321b6: enq 0x00000002483a2080(0x00000002483a2000) deq 0x00000002483a2000(0x00000002483a2000) segs 2 stream 0 bounce 1000 cycle 1
55.198903: xhci_ring_ep_doorbell: Ring doorbell for Slot 3 ep1in

The audio device probably sends the 1000 bytes per isoc tranfers as it stated, but
xhci expects 360 bytes, which leads to  buffer overrun errors

55.213952: xhci_handle_event: EVENT: TRB 00000002483a2000 status 'Isoch Buffer Overrun' len 360 slot 3 ep 3 type 'Transfer Event' flags e:C
55.222154: xhci_handle_transfer: ISOC: Buffer 0000000104735000 length 360 TD size 0 intr 0 type 'Isoch' flags B:i:I:c:s:I:e:C

Thanks
Mathias


  reply	other threads:[~2025-07-31 14:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-30 20:02 Audio interface causing "xhci_hcd ... WARN: buffer overrun event" messages Bob Ham
2025-07-31  8:17 ` Michał Pecio
2025-07-31  8:27   ` Michał Pecio
2025-07-31 10:11     ` Robert Ham
2025-07-31 14:26       ` Mathias Nyman [this message]
2025-08-02  8:43         ` Robert Ham
2025-07-31  9:56   ` Robert Ham
2025-07-31 10:04   ` Robert Ham
2025-07-31 20:21     ` Michał Pecio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f277779a-34af-4db0-bef0-fa41aa538f97@linux.intel.com \
    --to=mathias.nyman@linux.intel.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=michal.pecio@gmail.com \
    --cc=rah@settrans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox