Re: Problem with USB2 devices connected to a hub

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux