[How to] get an USB 3.0 HDD not recognized in a USB 3.1 port to work

Difficulty: ★☆☆☆☆

This tutorial was tested on a DELL laptop that came with two USB 3.1 ports and one USB 2.0. Unfortunately the external HDD (USB 3.0) was not recognised in this computer. It only worked in the USB 2.0 port (meaning slow access speeds) on both Linux and Windows.

The journalctl showed:

usb 1-1.1: device descriptor read/64, error -71

This Arch link was the basis for this solution:

The solution:

To solve the issue, you need to create a file '/etc/modprobe.d/modprobe.conf ':

sudo nano /etc/modprobe.d/modprobe.conf

with the following content:

options usbcore use_both_schemes=y

If that wouldn’t work try this instead:

options usbcore old_scheme_first=y

More Information:

Click the ▶ to the left of this text to expand this section

You may be able to avoid this problem by loading the usbcore.ko module with module parameter:


Alan Stern

The explanation of why Windows and Linux have the same problem can be found here..

The “old scheme” is the way Linux worked before 2.6.10. When a new device
is plugged in, the system first assigns it an address, then reads the
initial 8 bytes of the device descriptor, then reads the entire 18-byte
device descriptor.

The “new scheme” is basically the way Windows works. (Not surprisingly,
some devices won’t work any other way.) When a new device is plugged in,
the system first issues a 64-byte read request for the device descriptor,
then resets the device, then assigns it an address, and then reads the
actual 18-byte device descriptor.

The reason for these shenanigans is that with a full-speed device, the
maximum packet size for endpoint 0 (ep0maxpacket) isn’t known beforehand.
It could be 8, 16, 32, or 64 bytes. (Low-speed devices must use 8, and
high-speed devices must use 64.) The ep0maxpacket value is stored in the
initial 8 bytes of the device descriptor, but to read the device
descriptor you have to use endpoint 0!

The two schemes above are the two common solutions to this chicken-and-egg
problem. The old scheme is the one recommended by the USB Implementors
Forum (which makes it the “Standard”); the new scheme is the one used by
Microsoft (which makes it another kind of “Standard”!). A well-designed
standards-compliant device will work okay with either scheme.
Unfortunately it seems that no matter which scheme you pick, some
badly-designed non-compliant devices won’t work. There’s an additional
usbcore.ko module parameter people can use in especially bad cases:


This will cause the system to try one of the schemes, and if it fails then
try the other scheme. (Maybe that should always be the default…)

Alan Stern



Moved to #contributions:Tutorials, since I think this is a valuable contribution. The title was edited to better reflect the content.

Thank you @mbb!

1 Like