How to force a USB 3.0 port to work in USB 2.0 mode in Linux?

We know that we can disable USB 3.0 in the BIOS. But is there a way to force a USB 3.0 port to work in USB 2.0 mode inside of a running Linux?

On Linux on some platforms booted in BIOS modes, you can use the following command to force USB 2.0 modes for your USB ports:

# lspci -nn | grep USB \
| cut -d '[' -f3 | cut -d ']' -f1 \
| xargs -I@ setpci -H1 -d @ d0.l=0

Following is an explanation of what the commands do.

The controllers have a register XUSB2PR – xHC USB 2.0 Port Routing Register – at address 0xd0 (check http://www.intel.com/content/www/us/en/chipsets/7-series-chipset-pch-datasheet.html for more details). When the XUSB2PR register is set to 0, it routes all the corresponding USB 2.0 port pins to the EHCI controller and RMH #1. The USB 2.0 port is masked from the xHC and the USB 2.0 port’s OC pin is routed to the EHCI controller. The command setpci -H1 -d @ d0.l=0 does this.

setpci needs the vendor and device ID. So the first 2 lines find all USB controller’s IDs and pass them to xargs to invoke setpci.

If you would like to do the settings manually, one example is as follows for your reference:

# lspci -nn | grep USB
00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05)
00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 [8086:8c2d] (rev 05)
00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 [8086:8c26] (rev 05)

# setpci -H1 -d 8086:8c31 d0.l=0
# setpci -H1 -d 8086:8c26 d0.l=0
# setpci -H1 -d 8086:8c2d d0.l=0

The `dmesg` output example is as follows after setting `d0.l=0` for device `8086:8c3`:

[Fri Apr 10 13:24:30 2020] usb 3-1: USB disconnect, device number 8
[Fri Apr 10 13:24:30 2020] usb 2-1.1: new full-speed USB device number 6 using ehci-pci
[Fri Apr 10 13:24:30 2020] usb 2-1.1: New USB device found, idVendor=046d, idProduct=c52b
[Fri Apr 10 13:24:30 2020] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Fri Apr 10 13:24:30 2020] usb 2-1.1: Product: USB Receiver
[Fri Apr 10 13:24:30 2020] usb 2-1.1: Manufacturer: Logitech
[Fri Apr 10 13:24:30 2020] logitech-djreceiver 0003:046D:C52B.0013: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1d.0-1.1/input2
[Fri Apr 10 13:24:32 2020] input: Logitech MX Master as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.2/0003:046D:C52B.0013/0003:046D:4041.0014/input/input20
[Fri Apr 10 13:24:32 2020] logitech-hidpp-device 0003:046D:4041.0014: input,hidraw1: USB HID v1.11 Keyboard [Logitech MX Master] on usb-0000:00:1d.0-1.1:1

The device is using the ehci-pci as from the message.

To set it back, after setting `d0.l=1` for device `8086:8c31`, the `dmesg` shows:

[Fri Apr 10 13:26:28 2020] usb 2-1.1: USB disconnect, device number 6
[Fri Apr 10 13:26:28 2020] usb 3-1: new full-speed USB device number 9 using xhci_hcd
[Fri Apr 10 13:26:28 2020] usb 3-1: New USB device found, idVendor=046d, idProduct=c52b
[Fri Apr 10 13:26:28 2020] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Fri Apr 10 13:26:28 2020] usb 3-1: Product: USB Receiver
[Fri Apr 10 13:26:28 2020] usb 3-1: Manufacturer: Logitech
[Fri Apr 10 13:26:28 2020] logitech-djreceiver 0003:046D:C52B.0017: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-1/input2
[Fri Apr 10 13:26:28 2020] input: Logitech MX Master as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.2/0003:046D:C52B.0017/0003:046D:4041.0018/input/input21
[Fri Apr 10 13:26:28 2020] logitech-hidpp-device 0003:046D:4041.0018: input,hidraw1: USB HID v1.11 Keyboard [Logitech MX Master] on usb-0000:00:14.0-1:1

Now the device is using the xhci_hcd as from the message.

Eric Ma

Eric is a systems guy. Eric is interested in building high-performance and scalable distributed systems and related technologies. The views or opinions expressed here are solely Eric's own and do not necessarily represent those of any third parties.

15 comments:

  1. I had a faulty usb flash drive which thanks to your post I fixed it.

    How can I use my USB 3.0 again?

  2. If I do so and I try to use my v4l device (Hercules Webcam), I get this in dmesg:

    [363965.965532] usb 3-1.2.1: new full-speed USB device number 10 using ehci-pci
    [363966.075645] usb 3-1.2.1: New USB device found, idVendor=06f8, idProduct=3009
    [363966.075647] usb 3-1.2.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
    [363966.202241] media: Linux media interface: v0.10
    [363966.236743] Linux video capture interface: v2.00
    [363966.275630] gspca_main: v2.14.0 registered
    [363966.294248] gspca_main: gspca_pac7302-2.14.0 probing 06f8:3009
    [363966.294791] input: gspca_pac7302 as /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.2/3-1.2.1/input/input24
    [363966.294928] usbcore: registered new interface driver gspca_pac7302
    [364011.422012] gspca_pac7302 3-1.2.1:1.0: alt 6 – bandwidth not wide enough, trying again
    [364011.488262] gspca_pac7302 3-1.2.1:1.0: alt 5 – bandwidth not wide enough, trying again
    [364030.522898] gspca_pac7302 3-1.2.1:1.0: alt 6 – bandwidth not wide enough, trying again
    [364030.589523] gspca_pac7302 3-1.2.1:1.0: alt 5 – bandwidth not wide enough, trying again
    [364321.331830] gspca_pac7302 3-1.2.1:1.0: alt 6 – bandwidth not wide enough, trying again
    [364321.377832] gspca_pac7302: reg_w_page() failed i: 42 v: 00 error -32
    [364321.456486] gspca_pac7302 3-1.2.1:1.0: URB error -71, resubmitting
    [364321.552482] gspca_pac7302 3-1.2.1:1.0: URB error -71, resubmitting
    [364321.648481] gspca_pac7302 3-1.2.1:1.0: URB error -71, resubmitting
    [364321.744484] gspca_pac7302 3-1.2.1:1.0: URB error -71, resubmitting
    [364321.840482] gspca_pac7302 3-1.2.1:1.0: URB error -71, resubmitting
    [364321.936491] gspca_pac7302 3-1.2.1:1.0: URB error -71, resubmitting

    The “bandwidth not wide enough, trying again” are new here, when I enable USB 3.0 again, I still got the URB error messages when I try to $ cat /dev/video0.

  3. If you add the ‘-t’ parameter, the commands that xargs builds and runs will be echoed.

    | xargs -t -I@ setpci -H1 -d @ d0.l=1
    instead of
    | xargs -I@ setpci -H1 -d @ d0.l=0

    in my case on a Dell Latitude E7440
    root@e7440:~# lspci -nn | grep USB | cut -d ‘[‘ -f3 | cut -d ‘]’ -f1 | xargs -t -I@ setpci -H1 -d @ d0.l=1
    setpci -H1 -d 8086:9c31 d0.l=1
    setpci -H1 -d 8086:9c26 d0.l=1
    root@e7440:~#

  4. The command seems not working on my Latitude E6440, any suggestion?

    # lspci -nn | grep USB
    00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 04)
    00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 [8086:8c2d] (rev 04)
    00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 [8086:8c26] (rev 04)

    # lspci -nn | grep USB | cut -d ‘[‘ -f3 | cut -d ‘]’ -f1 | xargs -t -I@ setpci -H1 -d @ d0.l=0
    setpci -H1 -d 8086:8c31 d0.l=0
    setpci -H1 -d 8086:8c2d d0.l=0
    setpci -H1 -d 8086:8c26 d0.l=0

      1. Thanks for the reply :)
        What I am trying to do is making a usb hub only work in USB 2.0 mode.

        I am trying to use an uhubctl (https://github.com/mvp/uhubctl) command to do per-port power switching with a usbhub, but the hub I have only support per-port power switching in USB 2.0 mode only. The hub is connecting on laptop which only has USB 3.0 port/

        By running the command, it will show following information. After execute your command, I still see USB 3.0 “Current status for hub 4-6 [05e3:0617 GenesysLogic USB3.0 Hub, USB 3.00, 4 ports]”.

        Is your command work on my scenario?
        Hope you can get my point.

        ./uhubctl
        Current status for hub 2-1 [8087:8000]
        Port 1: 0100 power
        …(omitted)
        Port 8: 0103 power enable connect [0a5c:5801 Broadcom Corp 5880 0123456789ABCD]
        Current status for hub 1-1.2 [05e3:0610 GenesysLogic USB2.0 Hub, USB 2.10, 4 ports]
        Port 1: 0100 power
        …(omitted)
        Port 4: 0100 power
        Current status for hub 1-1 [8087:8008]
        Port 1: 0000 off
        Port 2: 0507 power highspeed suspend enable connect [05e3:0610 GenesysLogic USB2.0 Hub, USB 2.10, 4 ports]
        Port 3: 0000 off
        Port 4: 0000 off
        Port 5: 0507 power highspeed suspend enable connect [0c45:649d CNFCH52K195010002SI1 Laptop_Integrated_Webcam_HD]
        Port 6: 0000 off
        Current status for hub 4-6 [05e3:0617 GenesysLogic USB3.0 Hub, USB 3.00, 4 ports]
        Port 1: 02a0 power 5gbps Rx.Detect
        Port 2: 02a0 power 5gbps Rx.Detect
        Port 3: 02a0 power 5gbps Rx.Detect
        Port 4: 0203 power 5gbps U0 enable connect [0b95:1790 ASIX Elec. AX88179 0000051BD298C6]

        1. Can you check whether your Linux is running on UEFI or BIOS boot mode? The method in this post may only work if your Linux is running in BIOS boot mode.

          1. I just tried the method in a Ubuntu 18.04 Linux box running under BIOS. The result is as expected. I added the example `demsg` output I got in the post for your reference.

  5. The command doesn’t work for AMD controllers, because that name is put into brackets

    ➜ ~ lspci -nn | grep USB
    05:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne USB 3.1 [1022:1639]
    05:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne USB 3.1 [1022:1639]

  6. I’m having the following issue in Fedora 35, even as root:

    [root@fedora nathan]# setpci -H1 -d 8086:9a13 d0.l=0
    setpci: No permission to access I/O ports (you probably have to be root).

    Do you have any idea how to fix this?

  7. If you are still getting this error even if you are root:

    setpci: No permission to access I/O ports (you probably have to be root).

    … and you are seeing “locked down from EFI Secure Boot mode; see man kernel_lockdown.7” messages in your dmesg, your problem may be because EFI Secure Boot is enabled. The OS restricts certain direct I/O calls in Secure Boot mode.

    Solution: disable Secure Boot in your BIOS.

Leave a Reply

Your email address will not be published. Required fields are marked *