On 15.04.19 20:10, Alan Stern wrote:
On Mon, 15 Apr 2019, Georg Chini wrote:
On 15.04.19 17:17, Mathias Nyman wrote:
On 12.4.2019 22.48, Georg Chini wrote:
On 08.04.19 08:46, Georg Chini wrote:
On 02.04.19 16:52, Mathias Nyman wrote:
On 28.3.2019 15.41, Mathias Nyman wrote:
The issue happens when only a single hub and a single device is
connected to the
USB subsystem. On my previous board, I had two USB dongles and
two sound
devices connected to the same hub and it worked without issues.
So I guess it
is not a real bandwidth limit. Somehow the hub seems to eat the
bandwidth.
git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git
bandwidth-debug
New traces using the bandwidth-debug testbranch could be useful,
even without the "available bandwidth"
support
Here are the traces. In the beginning, there is no USB device
connected. Then I connect a hub
(this time a simple 4 port USB 2.0 hub). After that I connect an USB
sound device to the hub.
Hope it helps.
Traces show secondary bandwidth error response from xHC hardware when
adding ISOC OUT endpoint 1:
321.773182: xhci_add_endpoint: State disabled mult 1 max P. Streams 0
interval 1000 us max ESIT payload 200 CErr 0 Type Isoc OUT burst 0
maxp 200 deq 00000000fffb2001 avg trb len 200
321.773198: xhci_configure_endpoint_ctrl_ctx: Add: slot 1out
321.773199: xhci_configure_endpoint: RS 00001 full-speed multi-TT Ctx
Entries 7 MEL 0 us Port# 2/0 [TT Slot 7 Port# 1 TTT 0 Intr 0] Addr 0
State enabled/disabled
321.773200: xhci_queue_trb: CMD: Configure Endpoint Command: ctx
00000000fffaf000 slot 8 flags d:C
321.773380: xhci_handle_event: EVENT: TRB 00000000ffffeb60 status
'Secondary Bandwidth Error' len 0 slot 8 ep 0 type 'Command Completion
Event' flags e:c
That endpoint only moves 200 bytes every 1ms (every FS frame), which
is 1.6Mbit/s.
There was another periodic endpoint added before this one, but it only
moves 4 bytes every 32ms, equals ~1kbit/s
which together are still far from the ~12Mbit/s supported by FS bus,
even with the TT think time etc.
Traces doesn't show any incorrect values being given to xHC hw in the
context either.
Only thing I can think of is that there are other parameters affecting
the available bandwidth calculations,
such as the average TRB length, and Link powermanagement related exit
latencies.
xhci specs say:
The xHC uses the value of the Average TRB Length field in the Endpoint
Context as a metric to help
compute the system bus bandwidth requirements of an endpoint. The
accuracy of this parameter is
particularly important for periodic endpoints. An xHC will use the
Average TRB Length and other metrics to
allocate/distribute system bus bandwidth to endpoints. These “other”
metrics are xHC implementation
specific and outside the scope of this specification.
I'm out for a week, so response will be slow.
-Mathias
So what you are saying is that it's a "bug" or "feature" of the C3858
CPU and can't be fixed, right?
An unfortunate feature of the xHCI design is that bandwidth
computations are all done internally by the xHC controller. There's no
way to tell _how_ they were done, what the results were in detail, or
to fix any mistakes.
Alan Stern
So what you are saying is still that the CPU has a bug because the
controller
seems to be integrated on the CPU:
00:15.0 USB controller: Intel Corporation Atom Processor C3000 Series
USB 3.0 xHCI Controller (rev 11)
Or can it be a firmware/board issue as well?
Georg
