1

When trying to perform fastboot commands, the transfer is always erroneous. A quick search points to certain incompatibility with USB 3.0 ports.

Forcing legacy USB 2.0 mode is not present in my BIOS settings and not possible on OS side so I would have to rely on a software solution, which looks at least feasible, as several sources offer a solution on Windows by adding the registry entries:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\18D1D00D0100" /v "osvc" /t REG_BINARY /d "0000" /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\18D1D00D0100" /v "SkipContainerIdQuery" /t REG_BINARY /d "01000000" /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\18D1D00D0100" /v "SkipBOSDescriptorQuery" /t REG_BINARY /d "01000000" /f

As such, my question would be: What would be the equivalent solution on Linux?

I attempted to search about BOS descriptor and container ID on Linux, but to no avail other than libusb sources.

Relevant dmesg logs:

[ 1467.568758] usb 1-1: new high-speed USB device number 8 using xhci_hcd
[ 1467.718322] usb 1-1: New USB device found, idVendor=18d1, idProduct=d00d, bcdDevice= 1.00
[ 1467.718325] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1467.718326] usb 1-1: Product: Android
[ 1467.718327] usb 1-1: Manufacturer: Google
[ 1467.718327] usb 1-1: SerialNumber: 832ec5e4
////// Here I executed `fastboot devices`
[ 1476.552829] usb usb5-port1: over-current condition
[ 1476.636501] usb usb6-port1: over-current condition
[ 1484.336743] usb usb5-port1: over-current condition
[ 1484.416485] usb usb6-port1: over-current condition
[ 1487.100726] xhci_hcd 0000:00:14.0: USB core suspending port 1-1 not in U0/U1/U2
[ 1487.100879] usb 1-1: USB disconnect, device number 8
[ 1487.100987] usb 1-1: Failed to suspend device, error -32
[ 1490.074492] ucsi_acpi USBC000:00: UCSI_GET_PDOS returned 0 bytes

1 Answer 1

0

After diving into the various documentation, here is how I managed to solve the problem:

echo -1 | sudo tee /sys/module/usbcore/parameters/autosuspend
echo '18d1:d00d:k' | sudo tee /sys/module/usbcore/parameters/quirks
echo 1 | sudo tee /sys/bus/usb/devices/1-1/power/pm_qos_no_power_off
echo | sudo tee /sys/bus/usb/devices/1-1/power/wakeup
echo on | sudo tee /sys/bus/usb/devices/1-1/power/control
echo -1 | sudo tee /sys/bus/usb/devices/1-1/power/autosuspend_delay_ms
echo n | sudo tee /sys/bus/usb/devices/1-1/power/usb2_hardware_lpm

Might be a bit redundant but it works. Change the USB port as per the port being plugged in. My device is a Xiaomi Mix 2S. Change 18d1:d00d to the hardware in question as appropriate.

Reference: https://www.kernel.org/doc/html/v4.15/driver-api/usb/power-management.html https://www.kernel.org/doc/html/v4.15/admin-guide/kernel-parameters.html?highlight=usb-storage.quirks

My reasoning is that,

  • The issue happens a bit non-deterministically (sometimes right after plugging in, sometimes even after a few queries to the bootloader), so is unlikely to be within fastboot itself. Power-related issues tend to manifest in such a way so I suspected this.
  • There is no dedicated driver for the device (lsusb -t) so usbcore and the "raw" USB device is likely the point of interest.

I am still not so sure about the underlying mechanism of power management and how it correlates to the Windows solution of bypassing the two queries. According to this, it might be the relation between BOS descriptors and LPM capacities.

Further expansions to this answer would be greatly appreciated.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .