On 30.08.2017 21:50, Curt Meyers wrote:
On 08/28/2017 06:00 AM, Mathias Nyman wrote:
On 19.07.2017 01:39, Curt Meyers wrote:
Hello,
I have a new USB3 camera that can only operate in isochronous mode. I can open
and stream data from the camera using guvcview. The camera has 3 interfaces,
two show up as uvc video devices. The interface I open claims a maximum
bandwidth dwMaxBitRate=73728000, I should be able to open many of these devices
on a USB3 interface based on bandwidth.
If I try to open 2 or more devices on any hardware except one particular
computer it fails and I get the message:
[ 6345.752365] usb 2-2: Not enough bandwidth for new device state.
[ 6345.752368] usb 2-2: Not enough bandwidth for altsetting 2
On the working computer I have run up to 5 devices from a single xhci
controller and a hub without any problem, it ran for hours. The working
computers belongs to someone else and has an i7-3770 processor (3rd
generation). The failing computers are all more modern and contain an i7-6600U,
i3-7700 and an E5-2620v3 with various supporting chipsets, the one I am
concerned with is a:
00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI
Controller (rev 31)
Initially this started on a 4.4 kernel, then I upgraded to 4.8 and it still fails. I got the owner
of the working machine to upgrade to 4.8 and it still works. Then I fetched and built 4.13 from the
"next" branch. I have poked around in the uvc code and in the xhci code and I can't
really get a handle on what is going on. I tried to force some different alternate settings, I have
modified the uvc code to fix other "quirky" cameras in the past but nothing seems to make
any improvements here.
I am looking for suggestions on what I can try next. I am attaching the output
from the usb device descriptor, this is a stereo camera that outputs depth data
on the second interface, to the 320x480 resolution is really the depth of two
pixels packet together. It is this resolution that I am trying to run but all
resolutions basically fail.
xhci configure endpoint command returned with a bandwidth, or secondarty
bandwidth error
because xHC hardware can't fulfill the bandwidth requested in xhci endpoint
context structure.
xhci endpoint context is filled with slightly modified values from the endpoint
descriptor
(like wMaxPacketSize, bInterval, bMaxBurst and Mult fields)
New kernel have tracing for the endpoint context, First thing would
probably be to check that the endpoint context look sane.
xhci tracing will generate a lot of data, It can be enabled with:
mount -t debugfs none /sys/kernel/debug
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
Then send me the content of
/sys/kernel/debug/tracing/trace
Thanks
Mathias
Did the log file I sent make any sense?
I sent it only to you, didn't want to email it through the list server.
Evaulate context command looks fine:
255.643878: xhci_queue_trb: CMD: Evaluate Context Command: ctx 0000000413e9d000
slot 4 flags C
255.643903: xhci_handle_event: EVENT: TRB 0000000413e9c560 status 'Success' len
0 slot 4 ep 0 type 'Command Completion Event' flags e:C
255.643903: xhci_handle_command: CMD: Evaluate Context Command: ctx
0000000413e9d000 slot 4 flags C
Configure endpoint command just returns with Bandwidth error
255.643930: xhci_queue_trb: CMD: Configure Endpoint Command: ctx
00000004143fa000 slot 4 flags d:C
255.644112: xhci_handle_event: EVENT: TRB 0000000413e9c570 status 'Bandwidth
Error' len 0 slot 4 ep 0 type 'Command Completion Event' flags e:C
255.644112: xhci_handle_command: CMD: Configure Endpoint Command: ctx
00000004143fa000 slot 4 flags d:C
Unfortunately config endpoint command doesn't log endpoint context in this log,
it should call trace_xhci_handle_cmd_config_ep(ep_ctx), I don't know why it's
missing.
But later on at Set TR Dequeue Pointer Command it logs the endpiont context:
259.147237: xhci_handle_cmd_set_deq: RS 00000 super-speed Ctx Entries 7 MEL 512
us Port# 19/0 [TT Slot 0 Port# 0 TTT 0 Intr 0] Addr 1 State configured
259.147238: xhci_handle_cmd_set_deq_ep: State stopped mult 1 max P. Streams 0
interval 125 us max ESIT payload 201326592 CErr 0 Type Isoc IN burst 2 maxp
1024 deq 00000003f9fd6510 avg trb len 3072
This looks odd, 201326592 bytes per ESIT, way too much. So much that I suspect
tracing decodes it wrong
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
