With the patch Andiry made i still get the bandwidth error. When reading on the UVC project page about a related microsoft cam: Despite being able to work with lower USB bandwidths, this device always requests the maximum possible bandwidth, even for the MJPEG format. Using two of those cameras connected to the same USB controller is thus impossible without hacking the driver. So i don't know how much a xhci controller reports back as max bandwidth to a usb2.0 device ? (it's the only device i have plugged in, so it must be able to get all) And just out of curiousity, is the max bandwidth of a xhci controller only higher for usb3 devices or also for usb2 ? I needed i could compile with xhci debug again. -- Sander [ 1235.434956] hub 9-0:1.0: state 7 ports 4 chg 0000 evt 0008 [ 1235.434968] hub 9-0:1.0: port 3, status 0101, change 0001, 12 Mb/s [ 1235.538018] hub 9-0:1.0: debounce: port 3: total 100ms stable 100ms status 0x101 [ 1235.640081] usb 9-3: new high speed USB device using xhci_hcd and address 3 [ 1235.674721] usb 9-3: skipped 1 descriptor after configuration [ 1235.674725] usb 9-3: skipped 6 descriptors after interface [ 1235.674728] usb 9-3: skipped 1 descriptor after endpoint [ 1235.674731] usb 9-3: skipped 28 descriptors after interface [ 1235.674735] usb 9-3: skipped 1 descriptor after endpoint [ 1235.674738] usb 9-3: skipped 4 descriptors after interface [ 1235.674740] usb 9-3: skipped 2 descriptors after interface [ 1235.674743] usb 9-3: skipped 1 descriptor after endpoint [ 1235.675334] xhci_hcd 0000:02:00.0: WARN: short transfer on control ep [ 1235.676329] usb 9-3: default language 0x0409 [ 1235.682583] xhci_hcd 0000:02:00.0: WARN: short transfer on control ep [ 1235.689707] xhci_hcd 0000:02:00.0: WARN: short transfer on control ep [ 1235.690703] usb 9-3: udev 3, busnum 9, minor = 1026 [ 1235.690703] usb 9-3: New USB device found, idVendor=045e, idProduct=076d [ 1235.702858] usb 9-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1235.709994] usb 9-3: Product: Microsoft® LifeCam HD-5000 [ 1235.715404] usb 9-3: Manufacturer: Microsoft [ 1235.719760] usb 9-3: usb_probe_device [ 1235.719763] usb 9-3: configuration #1 chosen from 1 choice [ 1235.719772] usb 9-3: ep 0x83 - rounding interval to 128 microframes [ 1235.726273] usb 9-3: Successful Endpoint Configure command [ 1235.726600] usb 9-3: adding 9-3:1.0 (config #1, interface 0) [ 1235.727460] xhci_hcd 0000:02:00.0: WARN: short transfer on control ep [ 1235.734262] usbserial_generic 9-3:1.0: usb_probe_interface [ 1235.734265] usbserial_generic 9-3:1.0: usb_probe_interface - got id [ 1235.734321] uvcvideo 9-3:1.0: usb_probe_interface [ 1235.734323] uvcvideo 9-3:1.0: usb_probe_interface - got id [ 1235.734337] uvcvideo: Found UVC 1.00 device Microsoft® LifeCam HD-5000 (045e:076d) [ 1235.742228] usb 9-3: Successful Endpoint Configure command [ 1235.749439] input: Microsoft® LifeCam HD-5000 as /devices/pci0000:00/0000:00:1c.1/0000:02:00.0/usb9/9-3/9-3:1.0/input/input6 [ 1235.761146] usb 9-3: adding 9-3:1.1 (config #1, interface 1) [ 1235.761180] usb 9-3: adding 9-3:1.2 (config #1, interface 2) [ 1235.761215] usbserial_generic 9-3:1.2: usb_probe_interface [ 1235.761217] usbserial_generic 9-3:1.2: usb_probe_interface - got id [ 1235.761266] usb 9-3: adding 9-3:1.3 (config #1, interface 3) [ 1235.761306] usbserial_generic 9-3:1.3: usb_probe_interface [ 1235.761308] usbserial_generic 9-3:1.3: usb_probe_interface - got id [ 1235.761338] drivers/usb/core/inode.c: creating file '003' [ 1235.765152] usb 9-3: ep 0x83 - urb len = 0x10 (16), addr = 0x79ded5c0, num_trbs = 1 [ 1255.976871] usb 9-3: ep 0x83 - urb len = 0x10 (16), addr = 0x79ded5c0, num_trbs = 1 [ 1255.986795] usb 9-3: ep 0x81 - rounding interval to 1 microframes [ 1255.993046] usb 9-3: Not enough bandwidth for new device state. [ 1255.998969] usb 9-3: Not enough bandwidth for altsetting 6 [ 1256.005636] usb 9-3: Successful Endpoint Configure command Monday, November 1, 2010, 7:16:22 PM, you wrote: > 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
