> -----Original Message----- > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > Sent: Tuesday, November 02, 2010 1:51 AM > To: Sander Eikelenboom > Cc: Xu, Andiry; linux-usb@xxxxxxxxxxxxxxx > Subject: Re: xhci isoc : Not enough bandwidth for altsetting 6 > > On Thu, Oct 28, 2010 at 04:45:47PM +0200, Sander Eikelenboom wrote: > > Hi Andiry / Sarah, > > > > I got another webcam(microsoft hd 5000) to test with xhci today (UVC > driver, usb2 device), > > - On a usb2 controller this gives no problem and i can grab video. > > - On the usb3/xhci nec controller i get "Not enough bandwidth for > altsetting 6" and can't grab video > > > > I have attached: > > - dmesg.txt > > - dmesg-debug.txt > > - lsusb.txt > > > > in dmesg i have: > > - first plugged the device in the usb2 controller and started > videograbbing, no problem > > - then unplugged and plugged into the usb3 controller and started > videograbbing, which doesn't work and gives an "Not enough bandwidth for > altsetting 6", although some other appear as well. > > > > in dmesg-debug-txt > > - rebooted with kernel config with xhci debug enabled > > - plugged the device in usb3 controller > > - tried to grab video > > Your log looks very odd to me. I think it is a bug in the xHCI driver, > but it's a very odd bug. Possibly the USB core is handling a bad > endpoint descriptor? Here's why I'm wondering: > > > [ 35.274513] xhci_hcd 0000:02:00.0: Allocating ring at > ffff880079635b40 > > 8 segments were allocated for the ring, so this code must have triggered > in xhci_endpoint_init(): > if (usb_endpoint_xfer_isoc(&ep->desc)) > virt_dev->eps[ep_index].new_ring = > xhci_ring_alloc(xhci, 8, true, mem_flags); > > > [ 35.274608] usb 9-3: ep 0x81 - rounding interval to 1 microframes > > [ 35.280701] xhci_hcd 0000:02:00.0: add ep 0x81, slot id 1, new drop > flags = 0x0, new add flags = 0x8, new slot info = 0x18300000 > > [ 35.280704] xhci_hcd 0000:02:00.0: xhci_check_bandwidth called for > udev ffff880078b18000 > > [ 35.280707] xhci_hcd 0000:02:00.0: New Input Control Context: > > [ 35.280710] xhci_hcd 0000:02:00.0: @ffff88007c3f9000 (virt) @7c3f9000 > (dma) 0x000000 - drop flags > > [ 35.280713] xhci_hcd 0000:02:00.0: @ffff88007c3f9004 (virt) @7c3f9004 > (dma) 0x000009 - add flags > - I don't know why this is adding slot context, that's probably a > separate bug. > A0 set to 1 I think it's correct. Refer to xHCI spec 4.6.6. > This is the endpoint context that I think the host controller is > complaining about: > > > [ 35.280806] xhci_hcd 0000:02:00.0: Endpoint 02 Context: > > [ 35.280808] xhci_hcd 0000:02:00.0: @ffff88007c3f9080 (virt) @7c3f9080 > (dma) 0x000000 - ep_info > > [ 35.280811] xhci_hcd 0000:02:00.0: @ffff88007c3f9084 (virt) @7c3f9084 > (dma) 0x00022a - ep_info2 > > The line above very odd. It means: > - bus error is 1 (which only happens if we find an isoc endpoint > with usb_endpoint_xfer_isoc()) The CErr field for isoc endpoints should be set to 0. Refer to xHCI 1.0 spec Table 57: Note: CErr does not apply to Isoch endpoints and shall be set to '0' if EP Type = Isoch Out ('1') or Isoch In ('5'). > - but the endpoint type is 4, which means a *control* endpoint. The EP Type field is 5 actually. It indicates an isoc in endpoint, correctly. > - max burst size is 2 - there's an endpoint in the lsusb output > with a wMaxPacketSize of > 0x0c00 2x 1024 bytes > so that's probably the endpoint we're adding. The max burst is > only set if this is a high speed device with an isoc endpoint. > - max packet size is *0* That's obviously a bug too. > Perhaps it's the bug here. 1024 indicates bit 10 = 1. When it's masked with 0x3ff, it becomes 0. The correct mask should be 0x7ff, USB2 spec says: For all endpoints, bits 10..0 specify the maximum packet size (in bytes). Sander, you can try the patch attached to see if it helps. Thanks, Andiry
Attachment:
isoc_ep_init.patch
Description: isoc_ep_init.patch
