Hello Paul,

On 19.12.2013 00:40, Paul Zimmerman wrote:
>> The exact same code works when the device is attached to the NEC
>> controller (transferring 33792 bytes per ISO packet as requested), but
>> fails on the Intel controller (transferring only 11264 bytes, exactly
>> 1/3 of the requested size).
> What are the values from the ISO endpoint's Endpoint descriptor and
> SuperSpeed Endpoint Companion descriptor?
Here's the relevant lsusb output:

      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               1
        bMaxBurst              10
        Mult                    2

> If the Mult value is 2 (bits 1:0 of the Companion descriptor's bmAttributes
> field) and the Intel controller is treating it as 0 for some reason, that
> would give you 1/3 of the requested size.
> Or perhaps it is a throughput issue; if the bInterval is 1, then 33792
> bytes every 128us is a pretty high data rate. Perhaps the Intel controller
> can't keep up.
Both assumptions are true for this descriptor. I've also found that when
plugging the Kinect into the NEC controller (which works), there's an
additional message in the kernel log:

Dec 18 09:28:02 flunder kernel: [23267.972204] usb 6-1: Parent hub
missing LPM exit latency info.  Power management will be impacted.

This message doesn't appear with the Intel controller. I'm not sure if
this is somehow related to the device caps - lsusb shows:

Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength           22
  bNumDeviceCaps          2
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
      Latency Tolerance Messages (LTM) Supported
    wSpeedsSupported   0x000c
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   2
      Lowest fully-functional device speed is High Speed (480Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat        2047 micro seconds
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000002
      Link Power Management (LPM) Supported
Device Status:     0x0001
  Self Powered

> Do you have USB debugging enabled (CONFIG_USB_DEBUG=y) in the kernel
> config? With the latest kernels that should cause the xHCI driver to print
> debug messages to the dmesg log. In earlier kernels you also have to enable
> CONFIG_USB_XHCI_HCD_DEBUGGING.
No, it's a stock Ubuntu kernel ATM. Thanks for the hint, I'll rebuild a
custom one with those flags enabled.

> Do you have a USB bus analyzer? That should show you exactly what is going
> on. If not, maybe you can capture a usbmon trace. I don't know anything
> about usbmon, but Alan Stern might be able to help with that.
I don't have access to a hardware bus analyzer. Would usbmon help in
that case? I thought usbmon logs the submitted URBs, but not necessarily
what the host controller actually sends out?

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to