Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
On Mon, 2019-06-24 at 16:40 +0200, Philipp Zabel wrote: > Hi, > > On Mon, 2018-05-21 at 15:03 -0700, Curt Meyers wrote: > > On 05/16/2018 04:55 AM, Mathias Nyman wrote: > > > On 15.05.2018 12:22, Michael Tretter wrote: > > > > Hi Mathias, > > > > > > > > On Tue, 10 Apr 2018 18:22:03 +0300, Mathias Nyman wrote: > > > > > On 09.04.2018 11:21, Michael Tretter wrote: > > > > > > On Tue, 20 Feb 2018 15:29:28 +0200, Mathias Nyman wrote: > > > > > > > On 16.02.2018 15:28, Michael Tretter wrote: > > > > > > > > On Mon, 29 Jan 2018 14:02:57 +0200, Mathias Nyman wrote: > > > > > > > > > On 19.01.2018 22:12, Philipp Zabel wrote: > > > > > > > > > > On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter > > > > > > > > > > wrote: > > > > > > > > > > > I found the old thread and it sounds exactly like my > > > > > > > > > > > issue. > > > > > > > > > > > Different > > > > > > > > > > > camera, but same xHCI controller. > > > > > > > > > > > > > > > > > > > > I have exactly the same issue with the xHCI controller of > > > > > > > > > > my > > > > > > > > > > laptop and > > > > > > > > > > "Oculus Sensor" USB3 isochronous mostly-UVC cameras: > > > > > > > > > > > > > > > > > > > > 00:14.0 USB controller: Intel Corporation Wildcat Point-LP > > > > > > > > > > USB > > > > > > > > > > xHCI > > > > > > > > > > Controller (rev 03) (prog-if 30 [XHCI]) > > > > > > > > > > Subsystem: Lenovo Wildcat Point-LP USB xHCI > > > > > > > > > > Controller > > > > > > > > > > Flags: bus master, medium devsel, latency 0, IRQ 44 > > > > > > > > > > Memory at f222 (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 > > > > > > > > > > Kernel modules: xhci_pci > > > > > > > > > > > > > > > > > > > > T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 > > > > > > > > > > MxCh= 0 > > > > > > > > > > D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 > > > > > > > > > > P: Vendor=2833 ProdID=0211 Rev= 0.00 > > > > > > > > > > S: Manufacturer=Oculus VR > > > > > > > > > > S: Product=Rift Sensor > > > > > > > > > > S: SerialNumber=WMTD3034300BCT > > > > > > > > > > C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA > > > > > > > > > > A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00 > > > > > > > > > > I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 > > > > > > > > > > Driver=uvcvideo > > > > > > > > > > E: Ad=83(I) Atr=03(Int.) MxPS= 32 Ivl=128ms > > > > > > > > > > I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 > > > > > > > > > > Driver=uvcvideo > > > > > > > > > > I: If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 > > > > > > > > > > Driver=uvcvideo > > > > > > > > > > E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us > > > > > > > > > > I: If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 > > > > > > > > > > Driver=uvcvideo > > > > > > > > > > E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us > > > > > > > > > > > > > > > > > > > > Any USB2 or USB3 device that I plug in while the first > > > > > > > > > > camera > > > > > > > > > > is streaming in > > > > > > > > > > altsetting 1 or 2 causes the bandwidth error. The same > > > > > > > > > > happens > > > > > > > > > > when I try to > > > > > > > > > > change the altsetting on an isochronous endpoint of an > > > > > > > > > > already > > > > > > > > > > plugged device. > > > > > > > > > > While the camera is in altsetting 0, other devices can be > > > > > > > > > > probed and work. > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > Exactly the same thing helps here, as well. With this hack, > > > > > > > > > > streaming from two > > > > > > > > > > of those cameras at the same time works without any > > > > > > > > > > apparent > > > > > > > > > > problem: > > > > > > > > > > > > > > > > > > > > --8<-- > > > > > > > > > > diff --git a/drivers/usb/host/xhci.c > > > > > > > > > > b/drivers/usb/host/xhci.c > > > > > > > > > > index 297536c9fd00..3cb4a60d8822 100644 > > > > > > > > > > --- a/drivers/usb/host/xhci.c > > > > > > > > > > +++ b/drivers/usb/host/xhci.c > > > > > > > > > > @@ -4025,7 +4025,7 @@ static int __maybe_unused > > > > > > > > > > xhci_change_max_exit_latency(struct xhci_hcd *xhci, > > > > > > > > > > ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG); > > > > > > > > > > slot_ctx = xhci_get_slot_ctx(xhci, > > > > > > > > > > command->in_ctx); > > > > > > > > > > slot_ctx->dev_info2 &= cpu_t
Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
Hi, On Mon, 2018-05-21 at 15:03 -0700, Curt Meyers wrote: > On 05/16/2018 04:55 AM, Mathias Nyman wrote: > > On 15.05.2018 12:22, Michael Tretter wrote: > > > Hi Mathias, > > > > > > On Tue, 10 Apr 2018 18:22:03 +0300, Mathias Nyman wrote: > > > > On 09.04.2018 11:21, Michael Tretter wrote: > > > > > On Tue, 20 Feb 2018 15:29:28 +0200, Mathias Nyman wrote: > > > > > > On 16.02.2018 15:28, Michael Tretter wrote: > > > > > > > On Mon, 29 Jan 2018 14:02:57 +0200, Mathias Nyman wrote: > > > > > > > > On 19.01.2018 22:12, Philipp Zabel wrote: > > > > > > > > > On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter > > > > > > > > > wrote: > > > > > > > > > > I found the old thread and it sounds exactly like my issue. > > > > > > > > > > Different > > > > > > > > > > camera, but same xHCI controller. > > > > > > > > > > > > > > > > > > I have exactly the same issue with the xHCI controller of my > > > > > > > > > laptop and > > > > > > > > > "Oculus Sensor" USB3 isochronous mostly-UVC cameras: > > > > > > > > > > > > > > > > > > 00:14.0 USB controller: Intel Corporation Wildcat Point-LP > > > > > > > > > USB > > > > > > > > > xHCI > > > > > > > > > Controller (rev 03) (prog-if 30 [XHCI]) > > > > > > > > > Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller > > > > > > > > > Flags: bus master, medium devsel, latency 0, IRQ 44 > > > > > > > > > Memory at f222 (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 > > > > > > > > > Kernel modules: xhci_pci > > > > > > > > > > > > > > > > > > T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 > > > > > > > > > MxCh= 0 > > > > > > > > > D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 > > > > > > > > > P: Vendor=2833 ProdID=0211 Rev= 0.00 > > > > > > > > > S: Manufacturer=Oculus VR > > > > > > > > > S: Product=Rift Sensor > > > > > > > > > S: SerialNumber=WMTD3034300BCT > > > > > > > > > C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA > > > > > > > > > A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00 > > > > > > > > > I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 > > > > > > > > > Driver=uvcvideo > > > > > > > > > E: Ad=83(I) Atr=03(Int.) MxPS= 32 Ivl=128ms > > > > > > > > > I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 > > > > > > > > > Driver=uvcvideo > > > > > > > > > I: If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 > > > > > > > > > Driver=uvcvideo > > > > > > > > > E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us > > > > > > > > > I: If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 > > > > > > > > > Driver=uvcvideo > > > > > > > > > E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us > > > > > > > > > > > > > > > > > > Any USB2 or USB3 device that I plug in while the first camera > > > > > > > > > is streaming in > > > > > > > > > altsetting 1 or 2 causes the bandwidth error. The same > > > > > > > > > happens > > > > > > > > > when I try to > > > > > > > > > change the altsetting on an isochronous endpoint of an > > > > > > > > > already > > > > > > > > > plugged device. > > > > > > > > > While the camera is in altsetting 0, other devices can be > > > > > > > > > probed and work. > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > Exactly the same thing helps here, as well. With this hack, > > > > > > > > > streaming from two > > > > > > > > > of those cameras at the same time works without any apparent > > > > > > > > > problem: > > > > > > > > > > > > > > > > > > --8<-- > > > > > > > > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > > > > > > > > > index 297536c9fd00..3cb4a60d8822 100644 > > > > > > > > > --- a/drivers/usb/host/xhci.c > > > > > > > > > +++ b/drivers/usb/host/xhci.c > > > > > > > > > @@ -4025,7 +4025,7 @@ static int __maybe_unused > > > > > > > > > xhci_change_max_exit_latency(struct xhci_hcd *xhci, > > > > > > > > > ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG); > > > > > > > > > slot_ctx = xhci_get_slot_ctx(xhci, > > > > > > > > > command->in_ctx); > > > > > > > > > slot_ctx->dev_info2 &= cpu_to_le32(~((u32) > > > > > > > > > MAX_EXIT)); > > > > > > > > > - slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency); > > > > > > > > > + slot_ctx->dev_info2 |= cpu_to_le32(0); > > > > > > > > > slot_ctx->dev_state = 0; > > > > > > > > > > > > > > > > > > xhci_dbg_trace(xhci, > > > > > > > > > trace_xhci_dbg_context_change, >
Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
Hi Zhengjun, On Wed, 16 May 2018 14:55:55 +0300, Mathias Nyman wrote: > On 15.05.2018 12:22, Michael Tretter wrote: > > Hi Mathias, > > > > On Tue, 10 Apr 2018 18:22:03 +0300, Mathias Nyman wrote: > >> On 09.04.2018 11:21, Michael Tretter wrote: > >>> On Tue, 20 Feb 2018 15:29:28 +0200, Mathias Nyman wrote: > On 16.02.2018 15:28, Michael Tretter wrote: > > On Mon, 29 Jan 2018 14:02:57 +0200, Mathias Nyman wrote: > >> On 19.01.2018 22:12, Philipp Zabel wrote: > >>> On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter > >>> wrote: > I found the old thread and it sounds exactly like my issue. Different > camera, but same xHCI controller. > >>> > >>> I have exactly the same issue with the xHCI controller of my laptop > >>> and > >>> "Oculus Sensor" USB3 isochronous mostly-UVC cameras: > >>> > >>> 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI > >>> Controller (rev 03) (prog-if 30 [XHCI]) > >>> Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller > >>> Flags: bus master, medium devsel, latency 0, IRQ 44 > >>> Memory at f222 (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 > >>> Kernel modules: xhci_pci > >>> > >>> T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 > >>> D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 > >>> P: Vendor=2833 ProdID=0211 Rev= 0.00 > >>> S: Manufacturer=Oculus VR > >>> S: Product=Rift Sensor > >>> S: SerialNumber=WMTD3034300BCT > >>> C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA > >>> A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00 > >>> I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 Driver=uvcvideo > >>> E: Ad=83(I) Atr=03(Int.) MxPS= 32 Ivl=128ms > >>> I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > >>> I: If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > >>> E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us > >>> I: If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > >>> E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us > >>> > >>> Any USB2 or USB3 device that I plug in while the first camera is > >>> streaming in > >>> altsetting 1 or 2 causes the bandwidth error. The same happens when I > >>> try to > >>> change the altsetting on an isochronous endpoint of an already > >>> plugged device. > >>> While the camera is in altsetting 0, other devices can be probed and > >>> work. > >>> > 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. > >>> > >>> Exactly the same thing helps here, as well. With this hack, streaming > >>> from two > >>> of those cameras at the same time works without any apparent problem: > >>> > >>> --8<-- > >>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > >>> index 297536c9fd00..3cb4a60d8822 100644 > >>> --- a/drivers/usb/host/xhci.c > >>> +++ b/drivers/usb/host/xhci.c > >>> @@ -4025,7 +4025,7 @@ static int __maybe_unused > >>> xhci_change_max_exit_latency(struct xhci_hcd *xhci, > >>> ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG); > >>> slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx); > >>> slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT)); > >>> - slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency); > >>> + slot_ctx->dev_info2 |= cpu_to_le32(0); > >>> slot_ctx->dev_state = 0; > >>> > >>> xhci_dbg_trace(xhci, trace_xhci_dbg_context_change, > >>> -->8-- > >>> > >> > >> Ok, back after a week on sickleave. > >> I'm getting the magewell capture device and try to reproduce this > >> myself. > > > > I don't think that the issue is specific to the magewell capture > > device, but rather should be reproducible with any USB3 device with > > isochronous endpoints. > > > > Anyway, please tell me, if I can somehow help you to get this properly > > fixed. > > I'm currently looking at device reset issues after suspend, but this is > on the > todo list. > > I got a magewell device, (haven't unboxed it yet) > Maybe step by step instructions to reproduce it could speed things up. > >>> > >>> Did you have time to unbox and test the Magewell device? > >>> > >> > >> This seems to always get postponed due to other work, > >> > >> I just tried it out once today on a nearby
Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
On 05/16/2018 04:55 AM, Mathias Nyman wrote: On 15.05.2018 12:22, Michael Tretter wrote: Hi Mathias, On Tue, 10 Apr 2018 18:22:03 +0300, Mathias Nyman wrote: On 09.04.2018 11:21, Michael Tretter wrote: On Tue, 20 Feb 2018 15:29:28 +0200, Mathias Nyman wrote: On 16.02.2018 15:28, Michael Tretter wrote: On Mon, 29 Jan 2018 14:02:57 +0200, Mathias Nyman wrote: On 19.01.2018 22:12, Philipp Zabel wrote: On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter wrote: I found the old thread and it sounds exactly like my issue. Different camera, but same xHCI controller. I have exactly the same issue with the xHCI controller of my laptop and "Oculus Sensor" USB3 isochronous mostly-UVC cameras: 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03) (prog-if 30 [XHCI]) Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller Flags: bus master, medium devsel, latency 0, IRQ 44 Memory at f222 (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 Kernel modules: xhci_pci T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=2833 ProdID=0211 Rev= 0.00 S: Manufacturer=Oculus VR S: Product=Rift Sensor S: SerialNumber=WMTD3034300BCT C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 Driver=uvcvideo E: Ad=83(I) Atr=03(Int.) MxPS= 32 Ivl=128ms I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo I: If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us I: If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us Any USB2 or USB3 device that I plug in while the first camera is streaming in altsetting 1 or 2 causes the bandwidth error. The same happens when I try to change the altsetting on an isochronous endpoint of an already plugged device. While the camera is in altsetting 0, other devices can be probed and work. 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. Exactly the same thing helps here, as well. With this hack, streaming from two of those cameras at the same time works without any apparent problem: --8<-- diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 297536c9fd00..3cb4a60d8822 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4025,7 +4025,7 @@ static int __maybe_unused xhci_change_max_exit_latency(struct xhci_hcd *xhci, ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG); slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx); slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT)); - slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency); + slot_ctx->dev_info2 |= cpu_to_le32(0); slot_ctx->dev_state = 0; xhci_dbg_trace(xhci, trace_xhci_dbg_context_change, -->8-- Ok, back after a week on sickleave. I'm getting the magewell capture device and try to reproduce this myself. I don't think that the issue is specific to the magewell capture device, but rather should be reproducible with any USB3 device with isochronous endpoints. Anyway, please tell me, if I can somehow help you to get this properly fixed. I'm currently looking at device reset issues after suspend, but this is on the todo list. I got a magewell device, (haven't unboxed it yet) Maybe step by step instructions to reproduce it could speed things up. Did you have time to unbox and test the Magewell device? This seems to always get postponed due to other work, I just tried it out once today on a nearby laptop, gst-launch seems to work but couldn't reproduce the bandwidth issue when connecting a second usb device. But I haven't really tested it out properly yet. I just tested with 4.17-rc5 and the behavior remains the same. Is there anything else I could do to get this fixed? Briefed Zhengjun about this issue, one more brain on it. Adding him to the thread. Isochronous has been a problem for me for 2 years. I am using a rare 3D stereo camera from Etron and had Isochronous problems and recently I have discovered that the Logitech Brio also has what appears to be the same issue. The Logitech Brio is the first Logitech USB3 camera that uses Isochronous mode and you can do a search and find that linux users are having problems with it. My suggestion would be for the USB3 team to order several Logitech Brio cameras and debug the Isochronous problems. My company paid for someone to try and debug the problem and we came up w
Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
On 15.05.2018 12:22, Michael Tretter wrote: Hi Mathias, On Tue, 10 Apr 2018 18:22:03 +0300, Mathias Nyman wrote: On 09.04.2018 11:21, Michael Tretter wrote: On Tue, 20 Feb 2018 15:29:28 +0200, Mathias Nyman wrote: On 16.02.2018 15:28, Michael Tretter wrote: On Mon, 29 Jan 2018 14:02:57 +0200, Mathias Nyman wrote: On 19.01.2018 22:12, Philipp Zabel wrote: On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter wrote: I found the old thread and it sounds exactly like my issue. Different camera, but same xHCI controller. I have exactly the same issue with the xHCI controller of my laptop and "Oculus Sensor" USB3 isochronous mostly-UVC cameras: 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03) (prog-if 30 [XHCI]) Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller Flags: bus master, medium devsel, latency 0, IRQ 44 Memory at f222 (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 Kernel modules: xhci_pci T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=2833 ProdID=0211 Rev= 0.00 S: Manufacturer=Oculus VR S: Product=Rift Sensor S: SerialNumber=WMTD3034300BCT C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 Driver=uvcvideo E: Ad=83(I) Atr=03(Int.) MxPS= 32 Ivl=128ms I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo I: If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us I: If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us Any USB2 or USB3 device that I plug in while the first camera is streaming in altsetting 1 or 2 causes the bandwidth error. The same happens when I try to change the altsetting on an isochronous endpoint of an already plugged device. While the camera is in altsetting 0, other devices can be probed and work. 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. Exactly the same thing helps here, as well. With this hack, streaming from two of those cameras at the same time works without any apparent problem: --8<-- diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 297536c9fd00..3cb4a60d8822 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4025,7 +4025,7 @@ static int __maybe_unused xhci_change_max_exit_latency(struct xhci_hcd *xhci, ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG); slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx); slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT)); - slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency); + slot_ctx->dev_info2 |= cpu_to_le32(0); slot_ctx->dev_state = 0; xhci_dbg_trace(xhci, trace_xhci_dbg_context_change, -->8-- Ok, back after a week on sickleave. I'm getting the magewell capture device and try to reproduce this myself. I don't think that the issue is specific to the magewell capture device, but rather should be reproducible with any USB3 device with isochronous endpoints. Anyway, please tell me, if I can somehow help you to get this properly fixed. I'm currently looking at device reset issues after suspend, but this is on the todo list. I got a magewell device, (haven't unboxed it yet) Maybe step by step instructions to reproduce it could speed things up. Did you have time to unbox and test the Magewell device? This seems to always get postponed due to other work, I just tried it out once today on a nearby laptop, gst-launch seems to work but couldn't reproduce the bandwidth issue when connecting a second usb device. But I haven't really tested it out properly yet. I just tested with 4.17-rc5 and the behavior remains the same. Is there anything else I could do to get this fixed? Briefed Zhengjun about this issue, one more brain on it. Adding him to the thread. -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
Hi Mathias, On Tue, 10 Apr 2018 18:22:03 +0300, Mathias Nyman wrote: > On 09.04.2018 11:21, Michael Tretter wrote: > > On Tue, 20 Feb 2018 15:29:28 +0200, Mathias Nyman wrote: > >> On 16.02.2018 15:28, Michael Tretter wrote: > >>> On Mon, 29 Jan 2018 14:02:57 +0200, Mathias Nyman wrote: > On 19.01.2018 22:12, Philipp Zabel wrote: > > On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter > > wrote: > >> I found the old thread and it sounds exactly like my issue. Different > >> camera, but same xHCI controller. > > > > I have exactly the same issue with the xHCI controller of my laptop and > > "Oculus Sensor" USB3 isochronous mostly-UVC cameras: > > > > 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI > > Controller (rev 03) (prog-if 30 [XHCI]) > >Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller > >Flags: bus master, medium devsel, latency 0, IRQ 44 > >Memory at f222 (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 > >Kernel modules: xhci_pci > > > > T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 > > D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 > > P: Vendor=2833 ProdID=0211 Rev= 0.00 > > S: Manufacturer=Oculus VR > > S: Product=Rift Sensor > > S: SerialNumber=WMTD3034300BCT > > C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA > > A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00 > > I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 Driver=uvcvideo > > E: Ad=83(I) Atr=03(Int.) MxPS= 32 Ivl=128ms > > I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > > I: If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > > E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us > > I: If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > > E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us > > > > Any USB2 or USB3 device that I plug in while the first camera is > > streaming in > > altsetting 1 or 2 causes the bandwidth error. The same happens when I > > try to > > change the altsetting on an isochronous endpoint of an already plugged > > device. > > While the camera is in altsetting 0, other devices can be probed and > > work. > > > >> 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. > > > > Exactly the same thing helps here, as well. With this hack, streaming > > from two > > of those cameras at the same time works without any apparent problem: > > > > --8<-- > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > > index 297536c9fd00..3cb4a60d8822 100644 > > --- a/drivers/usb/host/xhci.c > > +++ b/drivers/usb/host/xhci.c > > @@ -4025,7 +4025,7 @@ static int __maybe_unused > > xhci_change_max_exit_latency(struct xhci_hcd *xhci, > >ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG); > >slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx); > >slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT)); > > - slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency); > > + slot_ctx->dev_info2 |= cpu_to_le32(0); > >slot_ctx->dev_state = 0; > > > >xhci_dbg_trace(xhci, trace_xhci_dbg_context_change, > > -->8-- > > > > Ok, back after a week on sickleave. > I'm getting the magewell capture device and try to reproduce this > myself. > >>> > >>> I don't think that the issue is specific to the magewell capture > >>> device, but rather should be reproducible with any USB3 device with > >>> isochronous endpoints. > >>> > >>> Anyway, please tell me, if I can somehow help you to get this properly > >>> fixed. > >> > >> I'm currently looking at device reset issues after suspend, but this is on > >> the > >> todo list. > >> > >> I got a magewell device, (haven't unboxed it yet) > >> Maybe step by step instructions to reproduce it could speed things up. > > > > Did you have time to unbox and test the Magewell device? > > > > This seems to always get postponed due to other work, > > I just tried it out once today on a nearby laptop, gst-launch seems to work > but couldn't reproduce the bandwidth issue when connecting a second usb > device. > > But I haven't really tested it out properly yet. I just tested with 4.17-rc5 and the behavior remains the same. Is there anything else I could do to get this fixed? Michael -- To unsubscribe from this list: send the line "unsubscribe lin
Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
On 09.04.2018 11:21, Michael Tretter wrote: On Tue, 20 Feb 2018 15:29:28 +0200, Mathias Nyman wrote: On 16.02.2018 15:28, Michael Tretter wrote: On Mon, 29 Jan 2018 14:02:57 +0200, Mathias Nyman wrote: On 19.01.2018 22:12, Philipp Zabel wrote: On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter wrote: I found the old thread and it sounds exactly like my issue. Different camera, but same xHCI controller. I have exactly the same issue with the xHCI controller of my laptop and "Oculus Sensor" USB3 isochronous mostly-UVC cameras: 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03) (prog-if 30 [XHCI]) Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller Flags: bus master, medium devsel, latency 0, IRQ 44 Memory at f222 (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 Kernel modules: xhci_pci T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=2833 ProdID=0211 Rev= 0.00 S: Manufacturer=Oculus VR S: Product=Rift Sensor S: SerialNumber=WMTD3034300BCT C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 Driver=uvcvideo E: Ad=83(I) Atr=03(Int.) MxPS= 32 Ivl=128ms I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo I: If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us I: If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us Any USB2 or USB3 device that I plug in while the first camera is streaming in altsetting 1 or 2 causes the bandwidth error. The same happens when I try to change the altsetting on an isochronous endpoint of an already plugged device. While the camera is in altsetting 0, other devices can be probed and work. 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. Exactly the same thing helps here, as well. With this hack, streaming from two of those cameras at the same time works without any apparent problem: --8<-- diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 297536c9fd00..3cb4a60d8822 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4025,7 +4025,7 @@ static int __maybe_unused xhci_change_max_exit_latency(struct xhci_hcd *xhci, ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG); slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx); slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT)); - slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency); + slot_ctx->dev_info2 |= cpu_to_le32(0); slot_ctx->dev_state = 0; xhci_dbg_trace(xhci, trace_xhci_dbg_context_change, -->8-- Ok, back after a week on sickleave. I'm getting the magewell capture device and try to reproduce this myself. I don't think that the issue is specific to the magewell capture device, but rather should be reproducible with any USB3 device with isochronous endpoints. Anyway, please tell me, if I can somehow help you to get this properly fixed. I'm currently looking at device reset issues after suspend, but this is on the todo list. I got a magewell device, (haven't unboxed it yet) Maybe step by step instructions to reproduce it could speed things up. Did you have time to unbox and test the Magewell device? This seems to always get postponed due to other work, I just tried it out once today on a nearby laptop, gst-launch seems to work but couldn't reproduce the bandwidth issue when connecting a second usb device. But I haven't really tested it out properly yet. -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
On Tue, 20 Feb 2018 15:29:28 +0200, Mathias Nyman wrote: > On 16.02.2018 15:28, Michael Tretter wrote: > > On Mon, 29 Jan 2018 14:02:57 +0200, Mathias Nyman wrote: > >> On 19.01.2018 22:12, Philipp Zabel wrote: > >>> On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter > >>> wrote: > I found the old thread and it sounds exactly like my issue. Different > camera, but same xHCI controller. > >>> > >>> I have exactly the same issue with the xHCI controller of my laptop and > >>> "Oculus Sensor" USB3 isochronous mostly-UVC cameras: > >>> > >>> 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI > >>> Controller (rev 03) (prog-if 30 [XHCI]) > >>> Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller > >>> Flags: bus master, medium devsel, latency 0, IRQ 44 > >>> Memory at f222 (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 > >>> Kernel modules: xhci_pci > >>> > >>> T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 > >>> D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 > >>> P: Vendor=2833 ProdID=0211 Rev= 0.00 > >>> S: Manufacturer=Oculus VR > >>> S: Product=Rift Sensor > >>> S: SerialNumber=WMTD3034300BCT > >>> C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA > >>> A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00 > >>> I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 Driver=uvcvideo > >>> E: Ad=83(I) Atr=03(Int.) MxPS= 32 Ivl=128ms > >>> I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > >>> I: If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > >>> E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us > >>> I: If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > >>> E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us > >>> > >>> Any USB2 or USB3 device that I plug in while the first camera is > >>> streaming in > >>> altsetting 1 or 2 causes the bandwidth error. The same happens when I try > >>> to > >>> change the altsetting on an isochronous endpoint of an already plugged > >>> device. > >>> While the camera is in altsetting 0, other devices can be probed and work. > >>> > 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. > >>> > >>> Exactly the same thing helps here, as well. With this hack, streaming > >>> from two > >>> of those cameras at the same time works without any apparent problem: > >>> > >>> --8<-- > >>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > >>> index 297536c9fd00..3cb4a60d8822 100644 > >>> --- a/drivers/usb/host/xhci.c > >>> +++ b/drivers/usb/host/xhci.c > >>> @@ -4025,7 +4025,7 @@ static int __maybe_unused > >>> xhci_change_max_exit_latency(struct xhci_hcd *xhci, > >>> ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG); > >>> slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx); > >>> slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT)); > >>> - slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency); > >>> + slot_ctx->dev_info2 |= cpu_to_le32(0); > >>> slot_ctx->dev_state = 0; > >>> > >>> xhci_dbg_trace(xhci, trace_xhci_dbg_context_change, > >>> -->8-- > >>> > >> > >> Ok, back after a week on sickleave. > >> I'm getting the magewell capture device and try to reproduce this myself. > > > > I don't think that the issue is specific to the magewell capture > > device, but rather should be reproducible with any USB3 device with > > isochronous endpoints. > > > > Anyway, please tell me, if I can somehow help you to get this properly > > fixed. > > I'm currently looking at device reset issues after suspend, but this is on the > todo list. > > I got a magewell device, (haven't unboxed it yet) > Maybe step by step instructions to reproduce it could speed things up. Did you have time to unbox and test the Magewell device? Michael -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
Hi Mathias, On Tue, 20 Feb 2018 15:29:28 +0200, Mathias Nyman wrote: > On 16.02.2018 15:28, Michael Tretter wrote: > > Hi Mathias, > > > > On Mon, 29 Jan 2018 14:02:57 +0200, Mathias Nyman wrote: > >> On 19.01.2018 22:12, Philipp Zabel wrote: > >>> Hi, > >>> > >>> On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter > >>> wrote: > I found the old thread and it sounds exactly like my issue. Different > camera, but same xHCI controller. > >>> > >>> I have exactly the same issue with the xHCI controller of my laptop and > >>> "Oculus Sensor" USB3 isochronous mostly-UVC cameras: > >>> > >>> 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI > >>> Controller (rev 03) (prog-if 30 [XHCI]) > >>> Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller > >>> Flags: bus master, medium devsel, latency 0, IRQ 44 > >>> Memory at f222 (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 > >>> Kernel modules: xhci_pci > >>> > >>> T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 > >>> D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 > >>> P: Vendor=2833 ProdID=0211 Rev= 0.00 > >>> S: Manufacturer=Oculus VR > >>> S: Product=Rift Sensor > >>> S: SerialNumber=WMTD3034300BCT > >>> C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA > >>> A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00 > >>> I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 Driver=uvcvideo > >>> E: Ad=83(I) Atr=03(Int.) MxPS= 32 Ivl=128ms > >>> I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > >>> I: If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > >>> E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us > >>> I: If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > >>> E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us > >>> > >>> Any USB2 or USB3 device that I plug in while the first camera is > >>> streaming in > >>> altsetting 1 or 2 causes the bandwidth error. The same happens when I try > >>> to > >>> change the altsetting on an isochronous endpoint of an already plugged > >>> device. > >>> While the camera is in altsetting 0, other devices can be probed and work. > >>> > 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. > >>> > >>> Exactly the same thing helps here, as well. With this hack, streaming > >>> from two > >>> of those cameras at the same time works without any apparent problem: > >>> > >>> --8<-- > >>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > >>> index 297536c9fd00..3cb4a60d8822 100644 > >>> --- a/drivers/usb/host/xhci.c > >>> +++ b/drivers/usb/host/xhci.c > >>> @@ -4025,7 +4025,7 @@ static int __maybe_unused > >>> xhci_change_max_exit_latency(struct xhci_hcd *xhci, > >>> ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG); > >>> slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx); > >>> slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT)); > >>> - slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency); > >>> + slot_ctx->dev_info2 |= cpu_to_le32(0); > >>> slot_ctx->dev_state = 0; > >>> > >>> xhci_dbg_trace(xhci, trace_xhci_dbg_context_change, > >>> -->8-- > >>> > >> > >> Ok, back after a week on sickleave. > >> I'm getting the magewell capture device and try to reproduce this myself. > > > > I don't think that the issue is specific to the magewell capture > > device, but rather should be reproducible with any USB3 device with > > isochronous endpoints. > > > > Anyway, please tell me, if I can somehow help you to get this properly > > fixed. > > I'm currently looking at device reset issues after suspend, but this is on the > todo list. > > I got a magewell device, (haven't unboxed it yet) > Maybe step by step instructions to reproduce it could speed things up. Here are the step by step instructions: 1. Connect Magewell device to USB 3.0 port. 2. Start using the created audio input to configure the isoch endpoint. I use pulseaudio (which should autodetect the device) and GStreamer for that, but anything should work. gst-launch-1.0 \ pulsesrc device='alsa_input.usb-Magewell_XI100DUSB-HDMI_A201170218035-02.analog-stereo' ! \ fakesink 3. Connect another USB device, e.g., a USB Stick, but it does not matter, to another port of the same controller. Expected behavior: usb 3-1: new high-speed USB device number 6 using xhci_hcd usb 3-1: New USB device found, idVendor=0951, idProduct=1665 usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-1: Product: DataTraveler 2.0 usb 3-1: Ma
Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
On 16.02.2018 15:28, Michael Tretter wrote: Hi Mathias, On Mon, 29 Jan 2018 14:02:57 +0200, Mathias Nyman wrote: On 19.01.2018 22:12, Philipp Zabel wrote: Hi, On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter wrote: I found the old thread and it sounds exactly like my issue. Different camera, but same xHCI controller. I have exactly the same issue with the xHCI controller of my laptop and "Oculus Sensor" USB3 isochronous mostly-UVC cameras: 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03) (prog-if 30 [XHCI]) Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller Flags: bus master, medium devsel, latency 0, IRQ 44 Memory at f222 (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 Kernel modules: xhci_pci T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=2833 ProdID=0211 Rev= 0.00 S: Manufacturer=Oculus VR S: Product=Rift Sensor S: SerialNumber=WMTD3034300BCT C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 Driver=uvcvideo E: Ad=83(I) Atr=03(Int.) MxPS= 32 Ivl=128ms I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo I: If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us I: If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us Any USB2 or USB3 device that I plug in while the first camera is streaming in altsetting 1 or 2 causes the bandwidth error. The same happens when I try to change the altsetting on an isochronous endpoint of an already plugged device. While the camera is in altsetting 0, other devices can be probed and work. 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. Exactly the same thing helps here, as well. With this hack, streaming from two of those cameras at the same time works without any apparent problem: --8<-- diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 297536c9fd00..3cb4a60d8822 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4025,7 +4025,7 @@ static int __maybe_unused xhci_change_max_exit_latency(struct xhci_hcd *xhci, ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG); slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx); slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT)); - slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency); + slot_ctx->dev_info2 |= cpu_to_le32(0); slot_ctx->dev_state = 0; xhci_dbg_trace(xhci, trace_xhci_dbg_context_change, -->8-- Ok, back after a week on sickleave. I'm getting the magewell capture device and try to reproduce this myself. I don't think that the issue is specific to the magewell capture device, but rather should be reproducible with any USB3 device with isochronous endpoints. Anyway, please tell me, if I can somehow help you to get this properly fixed. I'm currently looking at device reset issues after suspend, but this is on the todo list. I got a magewell device, (haven't unboxed it yet) Maybe step by step instructions to reproduce it could speed things up. Thanks Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
Hi Mathias, On Mon, 29 Jan 2018 14:02:57 +0200, Mathias Nyman wrote: > On 19.01.2018 22:12, Philipp Zabel wrote: > > Hi, > > > > On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter > > wrote: > >> I found the old thread and it sounds exactly like my issue. Different > >> camera, but same xHCI controller. > > > > I have exactly the same issue with the xHCI controller of my laptop and > > "Oculus Sensor" USB3 isochronous mostly-UVC cameras: > > > > 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI > > Controller (rev 03) (prog-if 30 [XHCI]) > > Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller > > Flags: bus master, medium devsel, latency 0, IRQ 44 > > Memory at f222 (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 > > Kernel modules: xhci_pci > > > > T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 > > D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 > > P: Vendor=2833 ProdID=0211 Rev= 0.00 > > S: Manufacturer=Oculus VR > > S: Product=Rift Sensor > > S: SerialNumber=WMTD3034300BCT > > C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA > > A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00 > > I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 Driver=uvcvideo > > E: Ad=83(I) Atr=03(Int.) MxPS= 32 Ivl=128ms > > I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > > I: If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > > E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us > > I: If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > > E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us > > > > Any USB2 or USB3 device that I plug in while the first camera is streaming > > in > > altsetting 1 or 2 causes the bandwidth error. The same happens when I try to > > change the altsetting on an isochronous endpoint of an already plugged > > device. > > While the camera is in altsetting 0, other devices can be probed and work. > > > >> 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. > > > > Exactly the same thing helps here, as well. With this hack, streaming from > > two > > of those cameras at the same time works without any apparent problem: > > > > --8<-- > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > > index 297536c9fd00..3cb4a60d8822 100644 > > --- a/drivers/usb/host/xhci.c > > +++ b/drivers/usb/host/xhci.c > > @@ -4025,7 +4025,7 @@ static int __maybe_unused > > xhci_change_max_exit_latency(struct xhci_hcd *xhci, > > ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG); > > slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx); > > slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT)); > > - slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency); > > + slot_ctx->dev_info2 |= cpu_to_le32(0); > > slot_ctx->dev_state = 0; > > > > xhci_dbg_trace(xhci, trace_xhci_dbg_context_change, > > -->8-- > > > > Ok, back after a week on sickleave. > I'm getting the magewell capture device and try to reproduce this myself. I don't think that the issue is specific to the magewell capture device, but rather should be reproducible with any USB3 device with isochronous endpoints. Anyway, please tell me, if I can somehow help you to get this properly fixed. Michael -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
On 19.01.2018 22:12, Philipp Zabel wrote: Hi, On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter wrote: I found the old thread and it sounds exactly like my issue. Different camera, but same xHCI controller. I have exactly the same issue with the xHCI controller of my laptop and "Oculus Sensor" USB3 isochronous mostly-UVC cameras: 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03) (prog-if 30 [XHCI]) Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller Flags: bus master, medium devsel, latency 0, IRQ 44 Memory at f222 (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 Kernel modules: xhci_pci T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=2833 ProdID=0211 Rev= 0.00 S: Manufacturer=Oculus VR S: Product=Rift Sensor S: SerialNumber=WMTD3034300BCT C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 Driver=uvcvideo E: Ad=83(I) Atr=03(Int.) MxPS= 32 Ivl=128ms I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo I: If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us I: If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us Any USB2 or USB3 device that I plug in while the first camera is streaming in altsetting 1 or 2 causes the bandwidth error. The same happens when I try to change the altsetting on an isochronous endpoint of an already plugged device. While the camera is in altsetting 0, other devices can be probed and work. 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. Exactly the same thing helps here, as well. With this hack, streaming from two of those cameras at the same time works without any apparent problem: --8<-- diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 297536c9fd00..3cb4a60d8822 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4025,7 +4025,7 @@ static int __maybe_unused xhci_change_max_exit_latency(struct xhci_hcd *xhci, ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG); slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx); slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT)); - slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency); + slot_ctx->dev_info2 |= cpu_to_le32(0); slot_ctx->dev_state = 0; xhci_dbg_trace(xhci, trace_xhci_dbg_context_change, -->8-- Ok, back after a week on sickleave. I'm getting the magewell capture device and try to reproduce this myself. -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
Hi, On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter wrote: > I found the old thread and it sounds exactly like my issue. Different > camera, but same xHCI controller. I have exactly the same issue with the xHCI controller of my laptop and "Oculus Sensor" USB3 isochronous mostly-UVC cameras: 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03) (prog-if 30 [XHCI]) Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller Flags: bus master, medium devsel, latency 0, IRQ 44 Memory at f222 (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 Kernel modules: xhci_pci T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=2833 ProdID=0211 Rev= 0.00 S: Manufacturer=Oculus VR S: Product=Rift Sensor S: SerialNumber=WMTD3034300BCT C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 Driver=uvcvideo E: Ad=83(I) Atr=03(Int.) MxPS= 32 Ivl=128ms I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo I: If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us I: If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us Any USB2 or USB3 device that I plug in while the first camera is streaming in altsetting 1 or 2 causes the bandwidth error. The same happens when I try to change the altsetting on an isochronous endpoint of an already plugged device. While the camera is in altsetting 0, other devices can be probed and work. > 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. Exactly the same thing helps here, as well. With this hack, streaming from two of those cameras at the same time works without any apparent problem: --8<-- diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 297536c9fd00..3cb4a60d8822 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4025,7 +4025,7 @@ static int __maybe_unused xhci_change_max_exit_latency(struct xhci_hcd *xhci, ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG); slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx); slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT)); - slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency); + slot_ctx->dev_info2 |= cpu_to_le32(0); slot_ctx->dev_state = 0; xhci_dbg_trace(xhci, trace_xhci_dbg_context_change, -->8-- regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
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/:00:14.0/devices cat 06/slot-context 0x00022b151000: RS 0 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/:00:14.0/devices cat 07/slot-context 0x00022b14d000: RS 0 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 f753 (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
Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
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 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. If you also could you send me the xhci debug and trace outputs just in case. Thanks Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
