On 05.12.2018 13:13, Tj wrote:
I'm assisting in debugging what appears to be a race condition in I2C
code [0] on Intel ComputeStick STK1A32SC [1] devices. As part of that
effort we were originally using an external USB<>RS232 adapter and
"console=ttyUSB0,115200n8" but that can be extremely slow (connected to
a real UART port) and the debug messages seem to prevent the issue occuring.
We decided to switch to use the XHCI debug port and ordered a set of
USB3 A<>A debug crossover cables [2].
We are following the kernel admin guide's USB3 debug port document [3]
We've hit problems in getting the DbC port to work correctly and need
some advice as to whether there is a kernel issue here?
The target is using custom-built 4.20-rc4 kernels with all required
modules built in. The original issue was first detected in Debian
kernels v4.18.*, but didn't occur in v4.9.
The ComputeStick devices have 2 USB ports, 1 is USB3, which the cable
connects to. The host is using v4.18.18 (Fedora) and has usb_debug
module loaded.
Initially the host reported:
usb 2-6: new SuperSpeed Gen 1 USB device number 9 using xhci_hcd
usb 2-6: LPM exit latency is zeroed, disabling LPM.
usb 2-6: language id specifier not provided by device, defaulting to English
usb 2-6: New USB device found, idVendor=1d6b, idProduct=0011, bcdDevice=
0.10
usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-6: rejected 1 configuration due to insufficient available bus power
usb 2-6: no configuration chosen from 1 choice
mtp-probe[32428]: checking bus 2, device 9:
"/sys/devices/pci0000:00/0000:00:14.0/usb2/2-6"
mtp-probe[32428]: bus: 2, device: 9 was not an MTP device
fwupd[2590]: failed to add USB device 1d6b:0011: 1d6b:0011 is not
supported: USB error on device 1d6b:0011 : Entity not found [-5]
Due to "rejected 1 configuration due to insufficient available bus
power" we then enabled the workaround:
# echo 1 > /sys/bus/usb/devices/.../bConfigurationValue
That got us further but then hits repeated -EPROTO errors:
usb 2-6: no configuration chosen from 1 choice
usb 2-6: new config #1 exceeds power limit by 660mA
usb_debug 2-6:1.0: xhci_dbc converter detected
usb 2-6: xhci_dbc converter now attached to ttyUSB0
xhci_dbc ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb
status: -71
The last line is repeated constantly several times each second.
The first thing that has confused us is where is the host getting the
"idProduct=0011" from? Looking at the xhci-dbgcap.h the only USB ID is
#define DBC_PRODUCT_ID 0x0010 /* device 0010 */
and xhci-dbgcap.c seems to write it without change:
dev_info = cpu_to_le32((DBC_DEVICE_REV << 16) | DBC_PRODUCT_ID);
usb_serial does declare both 0x0010 and 0x0011 as aliases but that
doesn't explain why the target is reported as 0x0011.
We're wondering if the warning:
"usb_serial_generic_write_bulk_callback - nonzero urb status: -71"
is a regression or bug, rather than us missing something, since we've
tried to do the same operation between two Fedora 4.18.18 PCs and got
exactly the same results.
Secondly, the "new config #1 exceeds power limit by 660mA" report, if we
calculate correctly, suggests that bMaxPower being sent by the target is
900mA + 660mA = 1560mA, but cannot find in the code where bMaxPower is
being set, if any. How is this set by the target?
The bMaxPower is set by xHCI vendor hardware,
For more details where about the DbC descriptors valjues see xhci specification:
section 7.6.10.1 for device descriptor (including Product ID)
section 7.6.10.2 for config descriptor (including bMaxPower)
https://www.intel.com/content/www/us/en/io/universal-serial-bus/extensible-host-controler-interface-usb-xhci.html
Any advice or experience as to what we might be missing?
What does sudo lsusb -v on the host say about the target device?
What's the dbc status on the target? you did enable it right?
(on target, cat /sys/bus/pci/devices/0000:00:14.0/dbc)
[0] https://bugs.freedesktop.org/show_bug.cgi?id=108714
[1] https://ark.intel.com/products/91064/Intel-Compute-Stick-STK1A32SC
[2]
https://www.datapro.net/products/usb-3-0-super-speed-a-a-debugging-cable.html
[3]
https://www.kernel.org/doc/html/v4.14/driver-api/usb/usb3-debug-port.html
