Hello Sarah, Monday, November 1, 2010, 6:50:34 PM, you wrote: > 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. Ok I will wait for you to prep a patch with extra debug info, have a good summit ! -- Sander > Sarah Sharp -- Best regards, Sander mailto:linux@xxxxxxxxxxxxxx -- 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
