On Thu, 18 Jan 2018 17:53:24 +0200, Mathias Nyman wrote:
> On 17.01.2018 18:46, Michael Tretter wrote:
> > Hello,
> >
> > I am using a Magewell XI100DUSB-HDMI frame grabber which by itself works
> > fine. However, I get a "Not enough bandwidth for new device state."
> > error for any other USB device that is plugged after the frame grabber.
> > This error is caused by the xHC sending a Bandwidth Error for
> > the Configure Endpoint command during xhci_check_bandwidth(). I
> > tested it with a USB-storage device (high speed and SuperSpeed) and a
> > USB 3.0 hub, but there is no difference. If I plug the frame grabber
> > after the other device, both work fine.
> >
> > The error only occurs, if Pulseaudio opened the device, which selects
> > an alternate interface for the AudioStreaming interface. This alternate
> > interface uses an isochronous endpoint with an interval of 1 ms and 192
> > BytesPerInterval. This should not reserve all bandwidth of the root
> > hub. I implemented the Get Port Bandwidth command to check the
> > available bandwidth of the xHC and it reports 80 % for HS ports, 90 %
> > for SS ports, and 0 % on the port used by the frame grabber. LGTM.
> >
> > I am currently testing on 4.15-rc8, but I can reproduce the same issue
> > with 4.12, too.
> >
> > This is the output of /sys/kernel/debug/usb/devices for the frame
> > grabber with the isochronous endpoint selected:
> >
> > T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=5000
> > MxCh= 0 D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1
> > P: Vendor=2935 ProdID=0001 Rev= 0.01
> > S: Manufacturer=Magewell
> > S: Product=XI100DUSB-HDMI
> > S: SerialNumber=A201170218035
> > C:* #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=800mA
> > A: FirstIf#= 0 IfCount= 2 Cls=0e(video) Sub=03 Prot=00
> > A: FirstIf#= 2 IfCount= 2 Cls=01(audio) Sub=01 Prot=00
> > I:* If#= 0 Alt= 0 #EPs= 1 Cls=0e(video) Sub=01 Prot=00 Driver=uvcvideo
> > E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
> > I:* If#= 1 Alt= 0 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
> > E: Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
> > I:* If#= 2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio
> > I: If#= 3 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
> > I:* If#= 3 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
> > E: Ad=85(I) Atr=05(Isoc) MxPS= 192 Ivl=1ms
> > I:* If#= 4 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
> > E: Ad=86(I) Atr=03(Int.) MxPS= 64 Ivl=64ms
> >
> > I don't understand, why the xHC sends the Bandwidth Error. I already
> > looked at the information about the xhci in the debugfs and the event
> > tracing, but I did not find anything relevant. Is there anything else
> > that I can look for and test
> Odd, there shouldn't be any bandwidth error in this case.
>
> There was one other case where bogus bandwidth errors for isoc transfers were
> reported. The reporter saw some correlation between the Bandwidth issues and
> LPM/MEL (Link power management/Max exit latency) settings.
>
> It could be worth disabling LPM, or just prevent changing the MEL to check if you see the same correlation.
I found the old thread and it sounds exactly like my issue. Different
camera, but same xHCI controller.
For some tests, I changed the xhci_change_max_exit_latency() function
to ignore the requested MEL and set the MEL to 0. Now the USB devices
are detected correctly.
These are the slot contexts for the devices. The first device is the
frame grabber, the second one is the device with the failed EP
configuration, which is still in addressed state.
/sys/kernel/debug/usb/xhci/0000:00:14.0/devices cat 06/slot-context
0x000000022b151000: RS 00000 super-speed Ctx Entries 13 MEL 2047 us Port# 19/0 [TT Slot 0 Port# 0 TTT 0 Intr 0] Addr 6 State configured
/sys/kernel/debug/usb/xhci/0000:00:14.0/devices cat 07/slot-context
0x000000022b14d000: RS 00000 high-speed Ctx Entries 1 MEL 0 us Port# 4/0 [TT Slot 0 Port# 0 TTT 0 Intr 0] Addr 7 State addressed
Further devices are detected correctly when the slot-context reports an
MEL of 2047 us and no isoch ep is selected.
> I might be able to get one of those devices.
> Do you have more detail (a testscript) on how to trigger the issue,
> and details about the xHCI host controller you are using.
00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31) (prog-if 30 [XHCI])
Subsystem: ASUSTeK Computer Inc. Device 8694
Flags: bus master, medium devsel, latency 0, IRQ 122
Memory at f7530000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [70] Power Management version 2
Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
Kernel driver in use: xhci_hcd
> If you also could you send me the xhci debug and trace outputs just in case.
I attached the dmesg output and the event trace for xhci_handle_command
and xhci_configure_endpoint.
There is an interesting sequence regarding the MEL, but I did not fully
grasp it, yet:
[ 118.205983] usb 2-3: Hub-initiated U1 disabled due to long timeout 132 ms
[ 118.205985] xhci_hcd 0000:00:14.0: Set up evaluate context for LPM MEL change: MEL 10 us
[ 118.205987] xhci_hcd 0000:00:14.0: // Ding dong!
[ 118.206020] xhci_hcd 0000:00:14.0: Successful evaluate context command
[ 118.206279] xhci_hcd 0000:00:14.0: Set up evaluate context for LPM MEL change: MEL 2047 us
[ 118.206281] xhci_hcd 0000:00:14.0: // Ding dong!
[ 118.206317] xhci_hcd 0000:00:14.0: Successful evaluate context command
[ 118.218567] xhci_hcd 0000:00:14.0: Set up evaluate context for LPM MEL change: MEL 0 us
[ 118.218574] xhci_hcd 0000:00:14.0: // Ding dong!
[ 118.218606] xhci_hcd 0000:00:14.0: Successful evaluate context command
MichaelAttachment:
dmesg
Description: Binary data
Attachment:
trace
Description: Binary data
