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.
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())
- but the endpoint type is 4, which means a *control* endpoint.
- 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.
I'm puzzled how xhci_endpoint_init() determines the endpoint is an isoc
endpoint, but xhci_get_endpoint_type() thinks it's a control endpoint,
and they both use usb_endpoint_xfer_isoc(). Possibly something else is
overwriting the fields later?
> [ 35.280960] xhci_hcd 0000:02:00.0: xhci_handle_event - calling handle_cmd_completion
> [ 35.280963] xhci_hcd 0000:02:00.0: Completed config ep cmd
> [ 35.280965] xhci_hcd 0000:02:00.0: Command ring deq = 0x78a3e080 (DMA)
> [ 35.280967] xhci_hcd 0000:02:00.0: xhci_handle_event - returned from handle_cmd_completion
> [ 35.280969] xhci_hcd 0000:02:00.0: Event ring deq = 0x78a3e660 (DMA)
> [ 35.280971] xhci_hcd 0000:02:00.0: In xhci_handle_event
> [ 35.280976] xhci_hcd 0000:02:00.0: `MEM_WRITE_DWORD(3'b000, 64'hffffc90000378638, 64'h78a3e668, 4'hf);
> [ 35.280982] xhci_hcd 0000:02:00.0: ERROR: unexpected command completion code 0x11.
And the NEC host rejects the new endpoint, and rightly so.
It's not obvious where the bug is, so I'm going to have to send you a
patch to add more debugging. I'm at the Kernel Summit right now, so the
patch may be delayed a week, sorry.
Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
